読者です 読者をやめる 読者になる 読者になる

リクルート住まいカンパニー Tech Blog

ITのちからで暮らしをよくしたい、エンジニア・デザイナーが発信するTech情報メディア

SUUMOスマホサイトでのChatOps事例

f:id:recruit-sumai:20170309110300p:plain

こんにちは。SUUMOスマホサイトの開発チームに所属している新人エンジニアの上野です。

本記事では、 SUUMOスマホサイトでのChatOps活用事例をいくつかご紹介したいと思います。

なぜChatOpsを導入したの?

突然ですがSUUMOスマホサイトでは、2週間毎に必ず1回はリリースを行なっています。

ところがChatOpsを導入する以前では、このリリース作業とそれに関わるモニタリング作業が課題になっていました。

 

具体的には・・・

1)開発生産性の低下:リリース作業には1時間程度かかり、開発者への負担となっていました。時間がかかるため、1日にリリースできる回数は必然的に限られ、また大変な作業であるがゆえにリリース自体を遅らせたりすることもありました。

2)作業の属人化:障害時のログ調査やリソースのモニタリング作業を特定の人だけが行っていました。特定のメンバーに負担が偏るだけでなく、属人化リスクも伴っている状況でした。

 

そこで、上記の2つの課題を解決するためにChatOpsを導入することになりました。

今回はChatOpsによる 1.リリースの自動化2.テストの自動化3.モニタリングの自動化についてご紹介したいと思います。

SUUMOスマホサイトで使っているツールたち

SUUMOスマホサイトにおいては、チャットツールとしてAtlassian社のHipChat、BotにはHubotを使用しています。 また他のツールとも連携させており、全体の構成としては以下のようになっています。

f:id:recruit-sumai:20170310104134p:plain

リリースの自動化

前提としてSUUMOスマホサイトでは、AWSを利用しており、リリース方式としてBlue Green Deploymentを採用しています。

そのため、新しく立ち上げたインスタンスへのリリースを行い、古いインスタンスと入れ替えるという作業が必要になるのですが、

手作業で行なうと、かなり非効率で人為的ミスのリスクも生じます※。

※AWSコンソール上でポチポチする作業や、立ち上げた複数のインスタンス内に入ってのリリース作業を想像してください

 

そのため、SUUMOスマホサイトにおいては、サーバの起動・停止などを含めたリリース作業をChat経由で行えるようにしました。

以下がリリース用コマンドの一例になります。

1)EC2の起動とEIPの付与を実行 f:id:recruit-sumai:20170310104233p:plain

2)起動したインスタンスへの新モジュールリリース f:id:recruit-sumai:20170310104325p:plain

こちらのコマンド自体はアプリケーション内に配置しているリリーススクリプトをキックさせているだけで、このスクリプトで設定ファイルの配備やアプリケーションの再配備などを行わせています。

3)ELBに紐づくインスタンスの切り替え f:id:recruit-sumai:20170310104402p:plain

これだけで、今まで手動で行っていて10分以上かかっていた一連のリリース作業を3つのコマンドを叩くだけで済ませられるようにしています。

テストの自動化(End to End; E2E)

SUUMOスマホサイトにおいては多数の画面やフォームから構成されており、それらを1つずつテストするのにかなりの工数がかかってしまいます。 そのため、最も重要なテストの1つである「各画面の資料請求ボタンがきちんと動作するかどうかの確認」のE2Eテストを自動化しています。 E2Eの自動テストにはSeleniumWebDriverを使用し、Gradle+Geb+Spock+PhantomJSといったソフトウェア群を用いてGroovyで記述しています。 これをJenkinsとHubotを組み合わせて、いつでも誰でも実行できるようにしています。 (E2E自動テストの構成や仕組みに関しては、後日記事を書きたいと思っているのでご期待ください。) f:id:recruit-sumai:20170310104436p:plain

以下の図が発行されたリンク先のE2Eテストのレポーティング結果ページになります。ここでは、SUUMOのサイトのCVである資料請求テストの全領域分のテスト結果を示してます。 f:id:recruit-sumai:20170310104504p:plain

モニタリングの自動化(キャパシティ・ログ監視)

キャパシティ監視においてもChatOpsを使用しています。 開発メンバー全員が4XX/5XX系のエラー状況やサーバのキャパシティを気にして欲しいため、毎日ランダムで担当者を割り当てています。 担当者はコマンドを実行し、Zabbixのグラフで日々のサーバの状態や4XX/5XX系のエラーを確認し、報告するようにしています。 f:id:recruit-sumai:20170310104535p:plain

コマンドを実行後に発行されるリンク先から、以下のようにCPU使用率やメモリ使用率などのZabbixグラフが表示されるようになっています。 f:id:recruit-sumai:20170310105022p:plain

また、例えば、5XXエラーが大量に発生していた場合には、ログ解析ツール(通称:suumon)で該当時間帯のアクセスログやアプリケーションログを確認して原因を調査するようにしています。 f:id:recruit-sumai:20170310105846p:plain

 

こんな活用方法も

実はSUUMOのスマホチームでは残業を少なくしようと、自主的に残業かっこわるいキャンペーンを実施しています。

ChatOpsのリマインダを利用して、定時になるとスーモbotが開発メンバーに呼びかけるようになっています f:id:recruit-sumai:20170310105918p:plain

ちなみに「残業カッコワルイヨ!!ストラップ」は下記にあるようなストラップで、一刻も早く帰りたくなるようにしています。    f:id:recruit-sumai:20170310110436p:plain

また、今日の運勢を占う「おみくじ」コマンドも存在しています。 開発メンバーが息抜きするときに使用しており、だれか一人が実行すると連鎖的に全員が占い始めることがよくあります。 f:id:recruit-sumai:20170310110001p:plain

 

課題

ChatOpsはメリットだけではなく、課題としてHubotの運用・保守が属人化し、特定の開発者の負担になりうることが挙げられます。

そのため、なんでもChatOpsに組み込むと運用・保守の工数が膨らんでかえって非効率的になってしまいます。

あたりまえではありますが、「開発工数 + 保守・運用工数 > 削減が見込まれる工数」となるタスクに関しては、ChatOpsに組み込まないように必要最低限に留める必要があるかと思います。

 

まとめ

以上が、SUUMOスマホサイトにおけるChatOpsの紹介になります。

今後はリリース作業の簡素化・自動化を更に進めることや、E2Eテストのテストシナリオの拡充などができればと考えております。

上記で挙げた課題点を考慮に入れた上でChatOpsを導入することにより、従来のChatでのメンバー間のコミュニケーションの円滑化に加え、属人化しがちな作業を誰でも行えることや、作業効率化などのメリットが生まれます。

ぜひChatOpsを実践してみてはいかがでしょうか?