はじめに

こんにちは。ホットペッパービューティーの開発をしています。長谷川です。

みなさん、夏休みはいかがでしたでしょうか。私は、久しぶりに田舎の祖母の家に遊びに行ってきました。いくつになっても（アラサーになっても…）孫扱いしてくれるのはうれしいですね！

さて、以前同僚の寺下が、ホットペッパービューティーのリプレイスのことを紹介していました。 Spring + Railsによるサービス分割の取り組み

同じプロジェクトで、Site Reliability Engineeringチーム(以下SREチーム）として、私も参加していたので、今回はインフラ面を中心に、リプレイスプロジェクトでの取り組みを紹介したいと思います。

背景となるいくつかの課題

私がこのプロジェクトに参画したのは、後半からだったので、方針であったり構成であったり、大まかなところは決まった状態でjoinしました。

その為、私が課題を分析をしたというわけではないのですが、既存システムのインフラや運用に関わる所だと、以下のような課題感があったようです。

• 労働集約的なオペレーションを行っていること
  • 手順書ベースのオペレーション作業などが行なわれていた。
• アジリティの低いシステムであること
  • 申請書ベースのインフラ変更作業や、リリースが「号切り」と呼ばれる、月に1度のビックバン的アプローチだった（bugfix等の緊急リリース等、例外はもちろん存在）。
• システムメトリクスのモニタリングに不備があること
  • 監視ツールは導入しているものの、項目が網羅されておらず、それを補完するための独自のツール類も、メンテナンスコストが高い状態だった。

これらの課題は、利用しているリクルートのプラットフォーム（オンプレミス環境）の課題とも密接に絡んでいました。プラットフォーム側の課題は、こちらの記事でも紹介されています。 リクルートの「リボンモデル」を支える仕事人–現場社員が語る、インフラエンジニアの現状

今回目指したこと

まず、SREチームとして仕事をするためにタスクを整理しました。そしてキックオフの際、以下のような方針を決めました。

ホットペッパービューティーがアジリティの高いシステムである、そういう状態をつくりたい

また、以下の定性状態を目指すことにしました。

• リリース作業
  • 開発者が自らの意図するタイミングで行う仕組みを整備する。
• システムモニタリングの整備
  • 開発者がシステムモニタリングをチェックしやすい仕組みを整備する。
• インフラのコード化
  • 開発者がインフラの変更作業を行えるように、コード化する。

ここに挙げたことは、世の中としては当たり前のことだと思います。今現在、目指すべきは更にその先でしょう。ただ、既存システムは世の中水準での当たり前ができていなかったので、とりあえず「当たり前」を目指しました。

実際にやったこと

ここでは、実際のアプローチの一部を紹介します。チームメンバーががんばってくれたので、私はほとんど応援していただけです^_^

リリース作業

リリース作業に伴う一連の作業は、手順書ベースの作業から、すべてRubyのThorを使い、コマンドラインツールとして実装しました。狭義のデプロイ作業としては、（Javaであれば）warのようなものを本番サーバに配置するだけですが、リリース作業全体としては以下のようなものがあります。

• リリース作業
  • CDNキャッシュクリア
  • 監視ツールのmute/unmute設定
  • ロードバランサーからのサービスアウト/サービスイン
  • デプロイ作業（アプリケーションの配置）
  • ツールによる動作確認
  • etc…

これら一連の作業をコマンドラインツールとして実装し、Jenkinsなどのjobとして組み込み、Pipelineとしています。下記の画像はPipelineのイメージです。

あえてコマンドラインツールとして実装しているのは、特定のCIツールに依存したくなかったのと、歴史的経緯で複数のCIツール（Jenkins及びTeamCity）を利用しているという背景があります。

これらを整備したことにより、リリースチームがリリースするのではなく、開発者が自由にリリースできる状態をつくることができました。

システムモニタリングの整備

モニタリングツールとして、今回はDatadogを利用しています。これは主にシステムメトリクス監視と、ログ監視をしています。

また、APM製品として、（既存システムでも使っていましたが）New Relicを利用しました。

DatadogのAPMも最近リリースされましたが、APMの機能でいうと、まだNew Relicに一日の長があるように思います。実際性能テストにて、New Relicの分析機能は大活躍しました。

Datadogを中心とした監視システムの全体像

上記は今回の監視システム全体の概念図となります。Datadog Agentをホストに導入して、システムメトリクスの監視をするのはもちろんのこと、アプリケーションログ等で、ERRORなどの文字列をfluentdで拾い、DogStatsdと連携させて、DatadogのEventとして登録しています。これによって、Datadogで情報の集約を行うことができ、その後のPagerDutyを使ったオンコールの仕組みなどと連携しやすくなっています。

すべてのログは、最終的にBigQueryに格納されており、開発者が生ログを確認したい場合は、redash経由でBigQuery内のログを検索できるようにしています。

インフラのコード化

申請書ベースのインフラ変更という文化を廃し、gitlab上のAnsibleが本番の構成と同等である状態を作りました。変更作業は当然Ansibleのリポジトリに対するMergeRequestとして運用しています。

終わりに

今回のプロジェクトでは、世間では使われているが、リクルートであまり使われていないテクノロジーを多く採用しました。（一例を上げると、Ubuntu,Redis,Ansible,Nginx,Datadog,PagerDutyなど）。

これらは私がすべて選定したわけではなく、それぞれ現状に課題意識をもったメンバーが、システムを良くするために必要だと判断し採用したものです。

リクルートライフスタイル（弊社）や、リクルートテクノロジーズ、ビジネスパートナーさん、それぞれのメンバーが「システムをより良くしたい」という気持ちで集まり、それを応援してくれる風土があったおかげで、今回のプロジェクトはなんとかリリースすることができました。

お約束ですが、アジリティの高いシステムをつくりたい！という方は、是非弊社にご応募頂ければと思います。