Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。gitlab-cichotaroです。豊洲PITでたくさんの人と頭の中のOMOIDEを共有してから一週間、興奮冷めやらぬ日々です。CIの実行時間を4分の1にしました。一度CIを動かすと1時間強待ちが発生する状況になっていたため、改善が急務でした。改善の結果と、どんなことをしたか自分の備忘も兼ねて書いておこうと思います。悩める人の参考になれば嬉しいです。before/after10月に改善を実施したので、9月と11月の比較になります。0:08:551回のpipelineにかかる時間がなんと4分の1以下になりました(๑•̀ᄇ•́)و✧せめて平均30分以内、を目指していたので大成功です!改善ポイント以下が主なポイントになります。imageを再利用するようにしましょう。executorのスペックを見直しましょう。毎回利用する外部リソース(依存するjarとか)が存在する場合、cacheを活用して使いまわしましょう。当たり前ですね!(※できてなかった基本的には公式documentの記述をもとにそれぞれの環境に当てはめていけばいい感じになります。それでは良いCIライフを!アデュー!......というのもあんまりなのでかなり泥臭い内容ですが、私の闘いの記録を残します。CIについて利用方法GitLab上で利用できるCIです。ドキュメントはこちら。)mざっくり概要ymlでjobや環境の設定を管理することができるgitlab-runnerというCIランナーをgitlab上のGUIで管理して利用する。executorがjobを実際に実行する。executorには様々なものを設定できる。(インスタンスについてはawsやgcpが利用可能。)我々の利用方法GCPインスタンス上でgitlab-runnerが動いているexecutorはdocker-machine形式により実行。dockerコンテナをそれ上で動かしてjobを実行する。現状を確認してボトルネックを明確にするjobの実行をgitlab上で観測するまずどう動いているのかがわからなかったので、ひたすら眺めてみました。gitlab-ciのjobのログをひたすら眺めるどこで詰まっているのかを調査するため、timeコマンドを挟むなどして実行時間を確認するgitlab-runnerにモニタリングツールを挿してもらうオートスケールの動き方など、どのようにexecutorがjobを処理していくのかをGUIで観測する手元でrunnerを立てて観測してみるリソースの状況などもっと詳細を確認したかったので手元でrunner、およびexecutorを立てて眺めてみました。更新されているものが何か、によって実行JOBを制御します。タイミングの制御:MRを立てている場合だけ実行する実行JOBの制御:該当directoryを変更している場合のみ実行する各JOBについて、以下のようにonlyを記載することで制御します。imageを使い回す利用しようとしているimageがすでにpullされている場合、新たにpullするのをやめるようにします。"if-not-present"cacheの仕組みを利用して、一度取得したjarを別のpipelineでも使い回すcacheを利用して、scalaの依存解決速度を爆速にします※cacheについての公式ドキュメントはこちらcacheの保存場所の設定を行わない場合、実行する環境でしかそのcacheを使い回せません。そのため、gcs上にcacheを保存するbucketを作成して、そこに保存するようにします。runnerの設定にて指定することができます。"<cacheを保存先のbucketのname>"cacheの保存先の設定ができたら、次にcacheを利用するようjobの設定を行います。ivyでの依存解決に時間がかかっていることがわかったので、.ivy2配下のcacheをpipelineを跨いで使い回すように設定します。${CI_PROJECT_DIR}/.ivy2/設定したら何度かjobを実行してみます。~~~と表示されるので確認しましょう。金で殴るともいうローカルでdockerに4コア使わせたところ、300%ほど利用していることがわかったので、スペックの調整をします。executorが起動するインスタンスの設定を修正します。...job設定に環境のスペックを確認するコマンドを入れるなどして反映されていることを確認しましょう。0:08:55とにかく改善しないと開発のスピードがバリヤバいという危機感から、一つ一つ調べたり、仮説を立てて実践を繰り返しました。効果があったのは何かと言われると明確ではないのですが、executorのスペックを見直してコンパイル速度を改善するが一つの鍵になり、そこ以外の地味な部分がすべて活用されるようになった結果劇的にjob時間が短くなった印象です。成果だけみると月間100時間短縮して素晴らしい改善効果なんですが、一方で「改善をあとに回した結果、数十ないし数百時間を無駄にしてしまっていた」という事実も浮き彫りに。早く問題意識を持って改善すべきだった事案です。gitlab-ciはまだ不慣れな面も多々あるのですが、今回の件でだいたいお友達になれたような気がします。来年はDeployフローの改善に着手したいところです。次回更新は年明け予定です。CIを四倍速にした話Tweet2019-12-12AI社員のつくり方フロントエンドエンジニアフロントエンドエンジニアをしているkitoです。今回は、Slackにいると便利なAI社員ことチャットボットについて書きたいと思います。翻訳から日々の業務サポートまで大活躍中というブログのエントリーを読んだことです。漠然と思うようになりました。実際、HISASHIくんにインスパイアされたAI社員をつくってみたので、その概要を書きたいと思います。DialogflowDialogflowは、Googleが運用開発している自然言語解析プラットフォームです。自然言語処理を丸投げできるので、対話型botをつくる際には本当に有り難いサービスです。これなしで気軽にチャットボットはつくれないでしょう。Editionの範囲なら無料で利用できます。今回、こちらのサービスを利用します。社内のヘルプデスク業務などを行うAI社員に必要な機能として最低限下記が必要かなと思います。気軽に話かけられるメンションつきの質問に答えられる正しい答えを学習させられるまず、気軽に話しかけるか否かですが、あまり難しく考えても仕方がないので、HISASHIくん同様いらすとやのイラストをアイコンにして、mizekoという名前にしました。(弊社、アスタミューゼなので。)DialogflowとSlackの連携メンションつきの質問に答えられるようにするのは、予想外に骨が折れました。Dialogflowには、Slack、Facebookなどと簡単に連携できるintegrationsという機能があり、当初これを利用すれば簡単にAI社員ができるのではと思っていました。実際には、@mizekoのようなメンションつきのテキストに反応するだけではなくて、あらゆるテキストに反応してしまい、チャットの邪魔になってしまいました。通常のチャットボットのユースケースならば発言する人が一人いて、それに随時反応すれば良いのかもしれませんが、会社のSlackで使う場合、様々な人がチャットに参加しているので、メンションつきもしくは特定のテキストにだけ反応して応答するようにしなければなりません。これを解決するために、integrationsを使うのではなく、すべてAPIを通じて受け答えするように変更しました。SlackのAPIでパブリックなチャンネルのテキストを取得し、@mizekoのメンションがついていた場合、DialogflowのAPIにテキストを投げ、解析の結果をSlackのAPIを通じて該当チャンネルに投稿するという流れです。URLを待ち受けるサーバーが必要になります。開発中や手元で試してみるなら、ngrokを使うのが簡単でしょう。本格的に試すならfirebaseが第一選択として考えられます。外部APIを呼ぶ場合は、有料プランのFlameかプランBlazeプランにする必要がある点注意です。Blazeプランの無料枠があるので、使い方によっては良い選択肢だと思います。私は、重量課金が少し気になったので他で用意しました。APPから新しいAPPを作成します。Tokenを控えておきましょう。events」でSubscribeするEventからmessage.channelsを選びます。URLをSubscribeしました。APIを参考にしてください。DialogflowのAPIDialogflowは、先にも書いたように自然言語解析プラットフォームでIntentというユーザーのリクエスト単位で管理されています。「今日の東京の天気教えて?」というユーザリクエストに、「東京は今日晴れです」と答えるのがひとつのIntentになります。今回のAI社員には、新規Intentを覚えさせ、またIntentをUpdateして再学習させなければなりません。要は、Slackのメッセージに応じて、DialogflowのAPIでIntentをCreateしたりUpdateしたりすることになるのですが、例えばAI社員が間違った回答をしたとき何を基準にIntentをUpdateすれば良いのでしょうか?メルカリさんのHISASHIくん場合、ブログのスクリーンショットから察すると、ある特定のチャンネルでの質問に対して、HISASHIくんの回答にスレッド形式で:hisashi:という絵文字をつけると正しい答えとしてみなして、後で?Updateしているようでした。このスレッド形式での正しい答えを絵文字つきで教える方式は、クレバーなやり方だと思ったので、弊社のmizekoでも採用しました。特定のチャンネルではなくすべてのチャンネルで、かつリアルタイムで学習して欲しかったので、APIでIntentをCreateもしくはUpdateするようにしました。events」で設定したのは、すべてのパブリックなチャンネルで、AI社員mizekoに質問でき学習させるためです。DialogflowのAPIに関しては、公式のリファレンスが参考になります。公式のサンプルをそのまま使えるので、最初の設定さえ間違えなければそれほど迷わないと思います。ポイントとしては、detectTextIntentでintentの検出を行い、帰って来た結果をSlackで返信するところです。languageCode);}また、Slackのメッセージがスレッドであるかは、channels.historyレスポンスのメッセージにthread_tsが含まれているかどうかで判断できます。スレッド上でのメッセージの場合は、:mizeko:という絵文字があれば、それは正しい答えを教えようとしているのだと判断できます。どのthreadが該当のthreadであるかは、conversations.repliesから導きだせます。Threadで正解を教え、もう一度同じ質問をすると正しく答えてくれます。(IntentのUpdateで上書きしているので、後から教えた方を覚えます)まとめメルカリのHISASHIくんにインスパイアされたAI社員をつくり、APIを通じて簡単な学習機能をつけました。Dialogflowコンソールからの手入力による柔軟な運用が必要になるのではないかという気もしますが、自動化できる部分は自動化して勝手に育ってくれると嬉しいですね。これからのオフィスでは、生産性を上げるためにBotがさらに活用されていくことでしょう。Botとうまく付きあって生産性を上げていきたいですよね?アスタミューゼでは、エンジニア・デザイナーを募集中です。ご興味のある方は遠慮なく採用サイトからご応募ください。