仕事の備忘録

IT系技術とか、カスタマーサービスとか

Amason Athena を業務利用した

2018年後半は社会人で初めて人手不足で忙しかった。人手は足りないのに仕事は増えるで必死に過ごした結果、初めて客先との会議中に寝る失敗をしたりとひどかったが無事2019年を迎えることができた。

夏からメインでやってたシステム、フロントエンドがReactでメインプログラマになり損ねたのであるが、こちらが無事リリースされた。バックエンド側も初めての構成だったがスケジュール費用とも想定内で収まり、かつ開発自体正直面白かった。そこでの知見を書く。

現在業務ではオンプレでSpark準拠のDWH(データウェアハウス)を利用している。UIはなくて各自SQLにてデータを取得する。このDWHのデータをUIで検索できるシステム提供が目的。SQLが書けない人にデータ提供したいのだ。

グループ内はAWSの各種システムが運用されているため、今回も経験者にてAWSでのシステム構築が検討された。しかし一番王道だと思われるAWS Redshiftは今回使えなかった。

aws.amazon.com

実証実験でDB構築して現行と同一速度になるまで課金した結果、月額換算で予算の5倍となることが判明したためである。今回の顧客はそこまでお金がないのでこの方法は取れなかった。そのため再検討でAthenaを利用する案が浮上した。

AWS Athena とはAWSが提供するサーバレスのS3検索システム。S3データをSQLで検索可能となる。

aws.amazon.com

詳細については色々ブログを探したが、こちらの方が2018年の記事でかつわかりやすかったので参考にしていただきたい。

www.casleyconsulting.co.jp

検証である程度の速度が担保できそうということで利用に踏み切った。

【現行システム概要】

データ内容

DWHの1テーブルにある1年間のユーザーアクセスログを検索する。

テーブルをtsv形式で出力して6.7G。年間で5700万レコード。tsvで6.8G。

テーブルのキーは日付、ユーザーID、商品ID。日付と商品IDを検索項目とする。

指定できる商品IDは最大1000。データ内のユーザIDは200万ID。

ユーザーごとに指定された商品IDでサマリー結果を出力する。

ヘッダが商品IDの1000カラム+ID単位1以上の値を持つ場合の0/1フラグで合計2000カラム、出力行数は200万レコードが最大となる。

データ検索と出力イメージ

2019-01-01から01-03までの検索レコードが以下のオレンジテーブルだった場合、出力は緑のテーブルのようになる。今回だとヘッダは3ID,出力レコード数も3レコードだ。

f:id:testedquality:20190119005535p:plain

要件

検索とcsv出力の2機能を搭載する。

検索は同時検索最大10人。かつ1日200回程度の検索を想定。

検索では件数と上位10件を表示、確認後OKならcsv出力を実施。

出力は非同期でOK。同時処理数は最大5JOB。

==================================================================

システム概要より最終的に構成を以下のように実施した。

【Athena構成】

①日付をキーとしたS3構成にする

現行DWHでのデータが日次処理であるため、検索条件と一致させるためS3の構成を 年→月→日 に設定。

②Apatch Parquet形式とする

データをAWSに送る際にはtsv.gzに変換して一日単位で持ってきていた。Athenaに利用するデータ形式は一番検索が早いということで、Apatch Parquetに変換。


parquet.apache.org

以下の記事を参考にしたと、提案してくれた人が教えてくれました。
dev.classmethod.jp

 

変換する際に1ファイルサイズを整えられるらしく、最初は128KBに分割されていた。しかし、試行錯誤中に海外の事例を見つけたメンバーが、1日1ファイルに1か月分を変換してして検索検証したところ、検索速度が半分以下に短縮された。

これよりデータをすべて作り直し1日1ファイルとしてS3に再配置を実施した。どうやらファイルサイズが小さすぎると検索のオーバーヘッドがあるらしい。

最終的に1年間で1.83G程度のデータ量となっていた。

【良かった点】

1.検索速度が現行DWHより早くなった

当初検索する商品ID指定の一覧表を実テーブル化、SQLでLeft join を行った。これは要求元の処理方法だった。

しかしAthenaではJOINするテーブルが増えると極端に速度が遅くなり、途中でメモリ不足となった。Athenaのメモリは提供されいている範囲のみで拡張はできない。要件を満たせないので、悩んだ末DWH利用者に最大IDの削減を相談した際にヒアリングさせてもらった。

そこでIDをSQLに直接指定する形で、集計関数を利用したSQLをExcelマクロで作成して検索していることが判明した。どうやら現場のみこのマクロを利用していたらしい。ヒアリング不足であった・・・・

この時のSQLを現行DWHで件数検索すると1000ID+フラグ1000カラムで5分かかることが判明した。

早速SQLを変更したところ、商品IDがSQLに記載されることもあり、AthenaのSQL文字数最大値「262,144 バイト」に限りなく近づいたが、1年間、1000IDの集計を1分40秒で完了することを確認した。
docs.aws.amazon.com

ぜひ実証実験を最初にやってめどをつけて利用したほうがよい。

2.運用時のアクセス量が少ない時に利用すると、費用対効果が高い

Athenaは従量課金である。それも検索する際のデータスキャン量による。

今回期間指定が最大1年間だが、DBの利用頻度が1日200回程度の検索が想定されている。全員が1年間検索した場合、

1.83*200=372G が1日のスキャン料金となる。

30日で10.96T。課金は1Tあたり5$なので、10.96*5=54.8$  = 6000円弱(110円換算)

この金額でRedShiftを運用できない。RDSだと検索スピードがここまで早くできない。ので費用対効果は非常に良いといえる。

常時利用するようなシステムではないが、データ量は多いとき、Athenaは有効な選択肢だと思う。

3.S3を利用するのでデータ量増大でも費用を抑えられる

S3がストレージとして使えるので、DWHで利用しているすべてのデータが現在約1Tなのだがそれを全部検索対象にしても、現行オンプレの1/5以下に抑えられることが判明している。またストレージでのデータ損失についても安定度が高いこともあり安心できる。

【悪かった点】

1.更新処理ができない

SQLが使えるがUpdate文は使えない。だからデータ修正時にはParquet形式ファイルの作り直しになる。データ不備はありえるため、日次転送用プログラムとあわせてリカバリー用のプログラムを事前準備してもらった。どうしても更新が必要となるUIでの検索情報などの管理部分はAmazon RDSを利用している。

2.メモリを利用しすぎると同一処理数を4以下に削減されることがある
先ほどのサービス制限にAPIごとの「1 秒あたりのデフォルトの呼び出し数」があるが、検索に関わるAPIについては5回と記載がある。

これより同一処理は5件までできるのだと判断。同時処理を5JOBとして管理するように設計した。

開発後の負荷テストでは、検索での件数取得いわゆるcount(*)や上位10件の表示は、前述の1年間1000IDを10人同時に実施して、順次10JOB が正常終了することを確認した。

しかしファイル出力の同時処理テストを実施した際に、1JOBづつのプロセスを5JOB用意し同時に処理させたところ、4JOBしか処理されない現象が発生した。

コンソールには4つのJOBしか出てこない。初めは「JOBを設定し損ねた?」とテスターが確認し、1JOB追加してみたがコンソールには出てこない。そのうちテストと平行で検索をしていた私は、画面での件数チェックでシステムが返答しなくなったのを確認して、Athenaがなんらかの障害を起こしていると判断した。

処理を一度中断させて、サポートにJOBの動作について確認を実施したところ、

「メモリ利用量によって、最大のJOB数を変更するのは仕様である。サービス制限のページに書かれている5JOBは、あくまでもデフォルトの呼び出し数であり、メモリ利用状況によってこの数を変更することはある。」との返答を頂いた。

5JOBの要求満たせないじゃん!

と返答のメールをみて開発者全員で天を仰いだ。

今回は4JOBでサービス制限がかかってしまい、Athenaのサービス全般が停止したのだ。これにより検索など画面に利用する部分の処理も待機、システムが停止することになったのだ。

サービス停止するJOB数を同時実行させるわけにはいかず、想定最大のSQLを全員が実行したときを考慮し、同時処理数を3JOBまで減らすことにした。お客様も普段AWSを利用していて状況を把握していただいたこと、出力処理が遅くても問題がないことよりご了承を頂けたのが幸いであった。負荷テストして本当に良かった。

Athenaのメモリ利用量の制限値は非公開のため、ここは負荷テストにて利用時必ずチェックしないといけない。

【まとめ】

ということで、Athena によってシステム構築をして満足している。DBよりチューニングできる箇所は少ないが、AWSが提供する潤沢なリソースを割安で利用できる点で検討に値すると思う。お客様からも早さと安さで高評価を受けていてちょっとうれしい。

あと、今回はAthenaを提案してくれたメンバーのおかげであるので、メンバーに感謝している。選択したとき、他部署の人はだれもそれをよしとはしなかっただけど、無事顧客に価値を提供できたのですべてよしである。

第12回 SQL Server 2019勉強会(1st Anniversary) に参加してきた その2

昨日途中だったので勉強会の報告その2。今回は途中退席するまでとなるがツイートで思い出して記載する。登壇者小澤さんブログは日本全国SQL Serverの使い手で知らない人はいないはずだがリンクを貼っておく。

blog.engineer-memo.com

先に始まった質問コーナーが一通り終わったので2019詳細解説が始まった。本日のセッションは資料公開がないため、写真撮影をしてほしいとのことだった。しかし写真が下手なのでツイートで文字起こしを兼ねたメモをした。

ここで小澤さんのKubernetesを使ったデモンストレーションが始まった。

2017から対応されたSQL Server On Linux のようなプラットフォーム複数対応、その後Dockerによるコンテナ対応、そして2019になってのKubernetes での利用や多種のDBを直接統合する様子は、まるで塊魂。Data Pratform データ統合ってこういうことかと話を聞きながら感動した。一方もうLinuxを使わずにSQLServer の新機能を使うことはできない。この辺り国内だと多いはずのWindows Serverのみを使っていたエンジニアには本当に厳しいなと思う。

この辺りのデモは小澤さんがAKSを使うのが楽でよいとのことだったので、さっそく来月の課題とする予定。現在IBM旧MSの戸倉さんのツイートが身に沁みる。

小澤さんのセッションは本当に別世界のようにSQL Serverが突き進んでいるのがわかり楽しかった。自分が業務でまた使うかわからないが、勉強だけはしておこう。面白い駆動である。

【初級者、中級者向け】SQL ServerのAzure移行のいろいろ

Ijimaさんが仕事でオンプレのSQL ServerをAzureに移行検討した際の調査結果紹介。まだテスト段階とのこと。

IjimaさんのSQL Serverをサーバリプレイスするにあたって

  • 現行サービスを止めずにデータ移行できること(オンライン移行)
  • T単位のデータ量である
  • サーバ管理者が自分しかいないのでAzureを使って手間を減らしたい

という点が課題。AzureのDBとしては、SQL Databaseがありますが、このDBは単一しか使えないので、インスタンスにDB二つなどオンプレだとよく実施していたパターンにはできない。そこでSQL Database Managed Instanceを調査したとのこと。

ちょうどMSが2日前に移行検討手順と資料を日本語で公開したのでリンクを記載しておく。

SQL Server から Azure SQL Database Managed Instance への移行【11/22更新】 – Microsoft Partner Network ブログ

この記事内にオンラインでの移行検討も記載がある。

IjimaさんはManaged Instanceが高いのでまだ実施までに至ってないということで発表は終了したが、その後皆さんから色々と意見がでていた。小澤さんからはManaged Instanceのもっと安いものが現在開発中との情報もあった。最低ラインで一月10万近いのだ。オンプレ版だとEnterpriseバージョンくらいのイメージだと思う。

また小澤さんが発表を聞いて以下を指摘していた。

移行をオンラインで行う場合通常業務に影響ないように通信経路を確保しないと、移行中に他のネットワーク操作ができないなど業務影響が甚大となる。T単位のデータだと通信帯域確保してないと(ここがExpress Routeが必要になる)いつまでも転送が終わらないかもしれないと、別の方も指摘していた。

ということでSQL Serverの勉強会に久方に参加したが、現状も今後も含めSQL Serverを使うためにまだまだ勉強しようとケツイするくらいには楽しい勉強会だった。また参加したいと思う。

 

第12回 SQL Server 2019勉強会(1st Anniversary) に参加してきた その1

本日SQL Serverの勉強会に参加してきた。

sqlserver.connpass.com

5月にde:code 2018に参加して以来の外部での勉強会となった。その間に仕事で初めてOffice365とPower BI とAzureを使い、最低限のレベルは確保できたがまだまだだと思った次第である。とりあえず最初から【初級者、中級者向け】SQL ServerのAzure移行のいろいろ までに参加することができた。参加した部分だけではあるが、ブログ書くまでが勉強会なので書く。

【初級者向け】SQL Serverのクエリ実行プランとパフォーマンス -SQL Serverエンジン、インディクスの基礎

今回は初心者向けに基礎テーマを行うとのことでクエリ実行プランの動作を詳細説明。そこでの一言が印象的であった。

SQLは書き方次第で本当にDBの動きを良くも悪くもする。最近どうしてもテーブルを複数結合するためにパフォーマンスが悪くなる仕様があり、1週間ほど悩んでお客様に相談したところ「あれ?数分もかからないはずだけど」という返答を頂いた。弊社親会社もグループ各社もシステム以外のほとんどの方がSQLをかける会社である。SQLをお願いしていただいたら大量のSUM関数をマクロで生み出していて、テーブル結合をせず実施していた。自分の思い込みの設計が誤っていたのだ。その時のことをこの言葉で思い出した。とにかくクエリ実行プランとその内部動作を知るとSQLをもっと早くできるので、勉強しておくべきだと思う。リソース増強より安くて手軽だ。

しかしこの辺りすっかり忘れており、MCP資格を2005の時に取得したのだがやり直しだなと思った次第。

【中級者、上級者向け】SQL Server 2019 最新情報 ReCap

Microsoft MVP - Data Platform Ozawaさんに聞くSQL Serverの質問会

私のブログに何度も出てくるムッシュ小澤さんによるSQL Server 2019情報、および質問会。小澤さんはMSの毎月実施しているSQL Server セミナーや、MSの大規模イベントでも解説されている国内で一番有名なSQL Server技術者である。過去ブログでは以下で発表者側として参加されている。 

testedquality-tech.hatenadiary.jp

testedquality-tech.hatenadiary.jp

testedquality-tech.hatenadiary.jp

今回は2019の解説であったが、プレゼン資料が配布されないとのことで写真OKだったものの私のカメラは性能が良くないので、ツイートでメモした。また解説資料が多いので質問を早めに終わらせようと、先にSQL Serverの質問会を行うことになった。

 msdbはSQL Serverのシステム用DBと呼ばれるもの。DBをSQL Server Integation Service をつかって移行作業をする場合、作成したスクリプトにはコンピューター名が含まれている。移行先ではコンピューター名変わることが一般的だと思うが、その場合コンピューター名が作成したスクリプトに直書きされているので、これを書き換える必要があるとのこと。スクリプトは平文となるので、手作業修正ができる。msdbの移行部分に埋まっているということなんですね。

 SQL Serverの新規作成時、デフォルトではDBファイルとログファイルの2種を1ファイルずつ(mdb,ldb)2ファイル作成できる。しかしDBファイルとログファイルを2つ以上指定することも可能だ。この新規作成時についての質問。

ファイルグループについては公式のドキュメントに記載がある。

データベース ファイルとファイル グループ | Microsoft Docs

昔から分割機能はあり、処理速度向上に役立つという記載もあるのだが、実際に運用していた際の自分の検討だと、バックアップの復旧を考えると分割によるリスク増大を許容できず見送った。せめてトランザクションログと別ディレクトリにするなどで、I/Oの効率UPを図るのがよさげだ。また、データサイズが大きいことを質問者の方が気にされていたが大きいからと言って圧縮だけは避けたほうがよいとのこと。理由が明確でなるほど!と思った。実際に私も仕事でストレージが不足して圧縮をしたときがあり、速度低下がユーザーの体感レベルで下がり問題になったことがあるので、みにつつまされた。

 トランザクションログもそうだがSQL Serverの物理ファイルは、一度大きくなるとレコードやテーブルを削除してもファイルサイズはそのままである。トランザクションログも同様。なのでトランザクションログのファイルサイズが大きい場合には、まず本当に中身が入っているのかを確認したほうがよい。統計情報でも見れるが、私は楽をするためデフォルトのレポートで見ていた。割合が円グラフで出てきて、他の人にもわかりやすい。 そのうえで中身がある場合、切り捨てが発生してない理由が何かあるはずで、それはシステムとログの状況を調べるしかない。ストレージを大きくするのをオンラインのままはできないので、業務が停止できない状況でログがむやみに増大するのは運用が厳しいだろう。

ということで質問がある程度落ち着いたところで2019の技術解説が始まった。

こちらも面白かったのだが、もう眠いので明日続きを書く。

初めて仕事で Microsoft Azure を使っている

私はTwitterのプロフィールにも書いているがMicrosoftが好きである。20年以上前のことを書かせてもらう。昔話になる。

本当に私は入社時システム開発に向いてないと思われていたし、自分もそう思っていた。大学は理系だったが、授業で習うホスト機でのプログラムを全く面白いと感じがことがなく最低限しかやらなかった。当時国立大でも情報処理の勉強はホスト機が主流だった。PC-9801でのゲームは高校の部活で遊んでいた程度でプログラムを学生時代にやることはなかった。

そんな私にプログラムが面白いと思わせてくれたのは、会社に入って2年目に国内発売されたばかりの日本語版Visual Basic 2.0 だった。というか、Cを研修で習っても全く頭に入らず困っていた私に上司が「お前はGUIのほうが向いている」と言って買ってくれたのだ。

当時まだまだホスト機全盛で、ホスト機を貸し出すだけで儲けが出る状態。一方ホスト機以外、Unix系OSやMS-DOSなどを使うコンピューターを「オープン系」と呼んでいたが、会社内では「子供のおもちゃ」とホスト機部署の人たちに揶揄されていた。そのおもちゃの筆頭がWindows 3.1 だった。

でも、そのおもちゃのおかげで、Cを挫折した私は自分でPCを買うくらいにプログラムが好きになった。香取慎吾が10代の頃にCMをしていたIBMのPCを購入したのはこのころ。36万したので物価を考えると当時のボーナスをそれにあてたはずだ。そのPCにインストールを最初にしたのがVisual Basic 2.0 だった。

そこからさらに数年後、Windows 95 が発売され「おもちゃ」と揶揄されたPCは仕事の道具して爆発的に普及した。最初はPCが嫌いで自分で触らず報告書なども「これ清書しといて」で済ませていた上司もいたが、あっという間にPCは一人一台となり提出物はWordになった。契約書や議事録を部下に書かせていた人たちは、結局社長への報告書をPCで書けず会社をリタイアしていったし、Unix系はホスト機から移行されるようになり、データセンター内にPCラックがあっという間にホスト機の場所を奪っていった。Visual Basic 2.0 Visual Basic 4.0になり業務アプリを簡単に作成できると流行り始め、Visual Basic 6.0になることには業務アプリ開発の一大勢力となった。

と、いうことを思い出すたび、何がいつ流行って廃れるか本当にわからないんで、いつも勉強しとかんといけないなと思う。システムの勉強を家でやるべきかどうかという議論がちょっと前にあったが、好きでやってる人が数多くいるIT業界なので、そこで生業とするための努力として勉強は必要だと思う。とにかく知識が少ない私の唯一のとりえは、プログラムを面白いと思える気持ちとあきらめが悪い点だから、しつこく勉強するしかないと考えている。ましてや私は子育て優先してて、時短勤務な時が長かったので、短時間でも会社にメリットである様な成果を出すしかなかった。

で、最近では Microsoft Azureも好きだ。これまた社内で利用事例がありつつもなかなか仕事としては使うことなく、もくもくと一人で触っていた。Bot作成やPower BI作成などもボッチ開発であった。しかし、つい先週から社内でAzureの仕事に携わるようになった。別件で初体験のReactも平行なので大変なこと限りないのであるが、初めて仕事でAzureを触って楽しくて仕方ない。

正直、これは神様が試していると思っている。仕事以外に今月来月は町内会もPTAも忙しくて、明日はお祭りで焼きそば売っているだろう。でもやる。やるったらやる。こんな時間にブログ書いて、誓うくらいうれしい。仕事で好きなことができる幸せを目いっぱい味わっておきたいと思う。

※夜中の文章は見直すべきなのですが勢いのまま掲載

UdemyでReactの勉強をしてる

前月よりReactの勉強継続中である。別の仕事も運用も家事もしながらで、なんといってもHTML5開発自体が初めてな状況、結構きつい。来月からの設計開発開始で既にAWSで構築するインフラ周りはむっちゃすごいエンジニア達がいて、すべてお願いして終わってしまったので顧客対応とか開発とか体張る覚悟まではしてみた。

ということでReact。採用理由は会社の諸事情で別システムとの連携を今後考慮する必要があり、そちらに移植を考えてのこと。別システムの方にレクチャーは受けられても自分が理解しないと開発はできない。レクチャーではReact本家のHandOnでの勉強を進められたが、英語の理解とReactの理解を一緒には無理な語学力の為、日本語での即戦力が欲しかった。そこで日本語のオンライン講習探してを買ってみた。まだ7割しか終わってないが結構役立っているので紹介をしておく。

買ったサービスはudemy。ゆーでみーと読む。世界展開しているサービスですが日本語版はベネッセが主管。

www.udemy.com

オンライン学習はほかにも色々あるが、React+Reduxまで扱っているコースがUdemyが充実していたのが理由。Progateとかドットインストールとか周りで評判よかったので使ってみたかったけど今回は断念。かつその時最大92%オフで、個人で買いやすかった。今見たらまだセール中な模様。下はReactで検索した結果のコース一覧。英語コースも一緒に出てくる。

f:id:testedquality:20180825230327p:plain

2本購入。1本はCodeSandboxという別サービスを使ってクライアントでのReact開発環境構築なしで勉強できるもの。ブラウザとネットがあれば講習を受けられるため、子供と一緒に漫画喫茶に行ってなど夏休み中助かった。またこちらはテキストですべての講習を公開していることもあり動画が見れない開発時などにも、勉強しやすかった。動画が禁止されているとかの人も大丈夫である。

www.udemy.com

もう一つはクライアント環境の作り方からすべて動画で提供。APIを使ったアプリケーションをシーケンス図などを使って業務的な観点での講習。クライアント環境の作り方を学べるのがありがたい。

www.udemy.com

勉強の成果は来週からのプロトタイプ作成からだ。週末で残りを終わらせて100%完了にしたいもんだ。全く何もできてないのだが自分を追い込むためにここに書いておく。

はてなブログhttps化完了。そして仕事で勉強すること

はてなのhttps化は無事に完了した。全3ブログをすべて実施。いまのところ5年前から行っている水産高校応援ブログでも苦情は来てないので何とかなっている模様。すでに25日よりChromeが予告通りの警告表示を開始しているため、間に合ってよかったと思っている。

internet.watch.impress.co.jp

さて、6月にボットを公開してから、仕事の勉強が大量に発生してLINE bot化に着手できてない。数年ぶりのフロントエンド&バックエンドの新規開発担当となったのだ。人手がないため優秀な方々がフルスタックな活躍をしているので、せめて足を引っ張らないように自分ができるところを広げるためには勉強しかない。

というと「偉いねー、私にはできない」と言われることがある。部署の方針で現業と平行、かつ家事のワンオペは続いているため残業は最低限となれば家や昼休みしか勉強する時間は取れないし、最新技術を常に見るべき仕事であるのでプライベートときっちり分けられるものでもないと考えるが、「私にはできない」というのは「あなたはおかしい」が割と含まれていることが多いのがつらい。

 

ということで現在Reactの勉強をオンラインとKindleで実施中。

reactjs.org

ReactはFacebook、Instagramが提供するJavaScript開発技術。フロントエンド開発向け。公式のチュートリアルがよいと別プロジェクトでReactを利用した会社の若者たちにいわれたものの、実際にやると概要が見えづらい(実は日本語訳があると先ほど知ったので後悔している)

React 0.13 日本語リファレンス | js STUDIO

本もあるのだがまだ全般発展中なので、若者曰く本通りに動かないことが多々ありストレスがたまるらしい。そこでKindleの電子書籍でアップデートがあるものを数冊購入して読んだ。しかしWindows版KindleをPCで開き、掲載ソースを動かすためコピーしようとしたら、コピー防止のためか不要な半角がソースコード全般に追加される極悪仕様でかえってストレスがたまることになった。

非常に悩んでいたところ、Twitter経由で90%オフの広告を出していたオンライン勉強サイトUdemyを数日前に知り、割引になっていて評判がよかったReactの有料セミナーを2つ買ってみた。オンラインドキュメントと動画とオンラインテキストの3種類。テキストがあれば動画をみなくてもよい親切設計で、会社でも勧めることができている。

www.udemy.com

セミナー7時間を想定しているようなので、終了したら評価を書きたいと思う。全部自腹で買ったし!

Web App Bot でSkype公開申請向けの修正を実施する その2

QnA Maker を使ったボットがSkypeからRejectされた。その修正対応の続きを書く。

testedquality-tech.hatenadiary.jp

先に結論からいうと正式にSkypeボットとして認証を得た状態で公開できた。以下の説明よりボットを見てもらったほうが早いかもしれない。単純に水産高校&商船専門高等学校を探すボットだ。インストール先は以下に掲載した。

botsuisangogo.hatenablog.jp

続きを読む