エンジニア視点で説明する「メルカリ」、リリースから4年の道のり：特集：情シスに求められる「SRE」という新たな役割（4）（2/2 ページ）

2017年6月、執行役員 Chief Business Officer（CBO）に、元Facebookのバイスプレジデント ジョン・ラーゲリン氏を迎えるなど、国内はもちろんグローバル展開も加速させているメルカリ。世界に支持される同社サービスはどのように作られ、支えられているのか？――2017年9月に開催された技術カンファレンス「Mercari Tech Conf 2017」にサービス開発・運用の舞台裏を探った。

[高橋睦美，＠IT]

マイクロサービスアーキテクチャの採用でオーナーシップ維持、ミスを前提とした自動化も

　最後に登場した名村卓氏は、ますますエンジニアが増え、多様性が高まる中、スケーラブルでエラスティックな技術集団を作っていくために、3つの行動指針を定義したと説明した。

名村卓氏

　1つは「オーナーシップ」。スケーラブルな組織には、自ら責任を持って決断することが不可欠だ。ただ、組織の規模が大きくなるにつれてオーナーシップが失われがちなことも事実。そこを保つために導入したのが「マイクロサービスアーキテクチャ」だという。

　既にコンテナやオーケストレーションといった技術とともに注目を集めているマイクロサービスアーキテクチャだが、「担当するチームも自然と小さく独立してくるため、何を使い、どのように進めるかについての裁量も自然と与えられる」（名村氏）点が大きいという。

　「マイクロサービスアーキテクチャならば、その役割にとって最適な言語を選択でき、それぞれにアーキテクチャを考える余地もある。マイクロサービスアーキテクチャ内でどのように実現されていようと、外部のインタフェースが担保されている限り、他のシステムは影響を受けない。（従来のやり方に対し）どちらでエンジニアのオーナーシップがより発揮できるかは一目瞭然だ」（名村氏）

　もちろん、機能ごとに独立するためテスト作業もシンプルになるし、デプロイも高速化でき、新たにエンジニアが加わったときの教育コストも低くなる。

　こうした考えから、メルカリ米国チームでは、クライアントアプリの書き換えを機に、マイクロサービスアーキテクチャを採用した。1つの大きなサーバサイドアプリによる構成だったものを、APIゲートウェイというレイヤーを被せる形に変更し、その内部でサービスコールをルーティングすることでスムーズな移行を実現したという。一部の機能については「『Google Cloud Spanner』という新たな分散データベースを採用するといった具合に、早速サービスごとに最適なアーキテクチャに挑戦する枠組みが実現できた」（名村氏）。

　なお、APIゲートウェイはDockerコンテナとして稼働しており、全体のオーケストレーションには「Kubernetes」を活用することで、マイクロサービスのデプロイも簡素化している。

全体のオーケストレーションに「Kubernetes」を利用してマイクロサービスのデプロイを簡素化

　2つ目は「オートメーション」と「からくり」だ。

　「組織が大きくなってくるにつれ、いろいろなものが複雑化してくる。気合いで何とかしたり、個人がミスしないことを前提に運用したりしていくのは難しい。そこで自動化できるものは全て自動化している」（名村氏）

　GitHubやJIRAと連携してデプロイをつかさどる「Go Bold ボット」や、リリースしたアプリがストアに反映された時間をチェックする「とんこつボット」、各種のアカウント作成を自動化した「アカウントクリエーションボット」の他、実デバイスを用いてテストを行い、問題があればSlackに自動的に通知する仕組みも整えている。

「気合いで何とかしたり、個人がミスしないことを前提に運用していくのは難しい。そこで自動化できるものは全て自動化している」

　また、メルカリでは、問題を起こした人（やその部下）が頭を下げれば問題解決、とは捉えていない。

　「問題が誰のせいで起きたかは誰も気にしないし、犯人探しもない。問題の根本を調査し、発見したら、ミスしても問題が起きない仕組みを作るようにしている。この仕組みが作られて初めて問題解決と見なしている。責任を取るのではなく、仕組みを作ることで問題を解決する」（名村氏）

　最後の指針は「プログレッシブ」。移り変わりの激しい世界の中で足を止めず、「Kotlin」やGoogle Cloud Spanner、「Apache Airflow」など、新たなテクノロジを積極的に取り入れていく姿勢だ。

　「次々に出てくる新しい技術を積極的に取り入れ、顧客により良い出品経験を提供していく」（名村氏）

　中でも2つ、特に力を入れて取り組んでいる技術がある。それが、機械学習とブロックチェーンだ。

　機械学習の分野では既に「チームAI」を設けており、入力された情報から価格や検索意図、嗜好を推定して、最適なコンテンツ配信につなげていきたいという。また、機械学習のエンジニアが得意分野でトレーニングに集中できるよう、マシンラーニング用のプラットフォームも開発中だ。データセットの読み込みやトレーニングクラスタの選定、モデルの保存、サービング、モデルの再評価といったプロセスを自動化し、エンジニアがモデルの構築に集中できる環境を提供する。

「チームAI」による機械学習プラットフォームの概念図

　「このプラットフォームが目指しているのは、機械学習のCI/CDや『継続的トレーニング』といったものだ。サーバアプリケーションをCI/CDで日々デプロイしているのと同じように、機械学習も継続的にモデルを開発する必要があるのではないかと考えている」（名村氏）

　GitHub上で動作するこのプラットフォームが完成した暁には、オープンソース化も検討しているという。

ホワイトボードからbot、そして次へ……メルカリのデプロイ環境の変遷

　カンファレンスでは、SREでサーバサイドデプロイを担当する佐々木健一氏が、「Mercariサーバサイドデプロイ:現在と未来」と題し、デプロイ環境をどのように改善してきたかを紹介した。柄沢氏の講演にも登場したSREは「いつでも安全で快適に使える信頼性の高いサービスの実現」を目的としたチームで、現在10人ほどのメンバーで運用しているそうだ。

SREの佐々木健一氏

　メルカリではデプロイするコードをGitHubで管理しており、マスターブランチにマージしたタイミングでデプロイを実行している。リリース時の事故を防止するため、「デプロイ前にマネジャーの承認を受けたか」「開発者同士のピアレビューが済んでいるか」「データベースのマイグレーションは済んでいるか」といった項目を確認してからマージし、デプロイする仕組みだ。これら確認項目は、ピアレビューやプルリクエストと結び付いた「イシューチケット」で管理しており、SREではこの「自動化」「からくり化」を進めてきたという。

　自動化以前は、週に一度まとめてリリースするという素朴な方法で管理していた。が、当然のことながら「人が増えてくると、一度にリリースすべき内容もどんどん膨らんでいく。『これは次のリリースに入れてほしい』『これがないとお客さまの要望に応えられない』といった声に応え、毎日緊急リリースするようになり、『週に一回』とルールを決めた意味がなくなってしまった」（佐々木氏）。そこで、基本的に金曜を除き毎日デプロイを行う形に変更した。

　だが今度は「要件を満たしているかを人間がチェックし、人間がサーバにログインしてリリースすることになった。つまり私が担当することになったが、非常につらい日々になった」（佐々木氏）。そこで、ちょうどSlackが社内でも普及してきたこともあり、Slack botでの自動化に取り組んだという。

　最初に作成したbotは、Googleカレンダーで予約されたデプロイすべき時間になると、Slackで自動的に呼び掛けてくれる。承認やピアレビュー、データベースのマイグレーションといった項目が満たされているかどうかのチェックはbotが自動的に行っているため、あとは「Yes」と答えるだけで、新しいコードでのマージとデプロイが行われる。

　「この方法で2017年までやってきたが、さらに人が増え、マイクロサービス化に取り組み始めると、botの仕事が大き過ぎることに気付いた」（佐々木氏）。そこで次に取り組んだのが、botの仕事を「レビューbot」と「デプロイbot」に切り分けることだ。「デプロイ前に満たすべき要件をチェックし、人間のようにレビューを行い、『ピアレビューが済んでいませんよ』といった事柄を教えてくれるレビューbotを分けた」（佐々木氏）。

　レビューbotは「AWS Lambda」と「Node.js」を活用しており、プロジェクト管理ツールの「JIRA」と社内の人事データベースを参照しつつ、GitHubAPI経由でラベルが付けられたレビューすべきコードをチェックする。OKであれば、デプロイbotがAnsibleのプレイブックを自動で呼び出しデプロイされる、という仕組みだ。

　佐々木氏は、レビューbotによるチェック結果をGitHubのどこに書き込むかでも試行錯誤したそうだ。下手にステータス欄やコメント欄に記述すると、開発・テスト作業の妨げになることもある。「主役は開発者であり、開発者の邪魔をしたらダメ。静かに見守るスタイルにして表示は最小限に留め、何か聞かれたら答えるようになっている」という。

開発者に対するきめ細かな配慮が込められたbotレビュー

　さらにSREでは、名村氏も触れた「マイクロサービスの導入を広げる中でのデプロイ」という新たな課題に取り組んでいる。具体的には、Netflixが開発した「Spinnaker」を用いて、Kubernetesに対応したデプロイの実現を目指しているという。

　「Spinnakerを使うことにより、ブルーグリーンなデプロイやカナリーデプロイといったデプロイ方法を自らプログラミング、コーディングし、オーナーシップを持ってデプロイメントパイプラインを開発できる点を評価し、採用している」（佐々木氏）

　早くも幾つかのマイクロサービスでSpinnakerを用いたデプロイを投入したそうだ。オープンソースソフトウェアになってからまだ日が浅く、情報量や安定性の面で課題はあるというものの、「まず1台のサーバだけにデプロイして、エラーレートやレスポンスタイムの低下がないかといった事柄を自動的に測定、可視化し、基準を満たさなければロールバックするといったオートメーテッドカナリーアナリシス（Automated Canary Analysis）の機能が付いており、そこに期待している」（佐々木氏）。

　将来的には、Spinnakerを一種の「先生」役として、マイクロサービス向けのデプロイ基盤の構築と、さらなるオペレーションの自動化に取り組んでいく計画だ。

メルカリが考える「これからのデプロイ」の在り方

　また「コードのデプロイだけでなく、機械学習向けにデータを拾い上げてきて学習させる『データデプロイ』の基盤も必要になるのではないかと考えている。さらに別の視点で、顧客のサポートに当たるカスタマーサービス向けに、いつ、どんな機能がリリースされたかを自動的に知らせ、分かりやすく示す仕組みを作りたい。お客さまからの質問にスムーズにお答えできる体制を作るため、空港におけるフライト情報のディスプレイのように、誰にでも分かる形で可視化することで、いつ、何が出るかを素早く正確に伝えたい」と佐々木氏は述べ、まだまだSREの挑戦は続くとした。

特集：情シスに求められる「SRE」という新たな役割

IoT、X Techトレンドの本格化に伴い、ニーズの変化に合わせて「いかにスピーディにITサービスを企画・開発するか」が重視されている。だがビジネス差別化の上で重要なのは「作ること」だけではない。リリース後の運用が大きなカギを握る。本特集では米グーグルが提唱する「SRE――Site Reliability Engineer（サイト信頼性エンジニア）」という概念を深堀りし、「運用管理のビジネス価値」を再定義する。

特集：情シスに求められる「SRE」という新たな役割