開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2018/11/06

失敗しがちなDevOps、メルカリ流「DevOps文化の醸成の仕方」とは

(後編)

メルカリはこの1年、マイクロサービスアーキテクチャにどう取り組み、実現のためになにをしてきたのか。技術面と組織面の双方に関する興味深い取り組みが、10月4日に都内で行われた同社主催の技術カンファレンス「Mercari Tech Conf 2018」のセッション「Microservices Platform at Mercari」で紹介されました。

新野淳一(本記事は「Publickey」より転載)

新野淳一(本記事は「Publickey」より転載)

ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。

photo

DevOps文化を組織内に醸成する

 次はDevOps文化の醸成です。

 この1年で、マイクロサービスの開発者が自分たちでできるようになったことが大きくふたつあります。

 ひとつ目は、インフラのセットアップとプロビジョニング。ふたつ目はサービスのデプロイです。

 まず、プロビジョニングから。

 先ほど、各開発チームがKubernetesのネームスペースやGCPのサービスにアクセスできるようにした、という話をしました。

 そこで例えばGCPのデータベースを使いたいときにはデータベースをセットアップする、という作業を行います。これがプロビジョニングです。

 われわれはこのプロビジョニングを「Infrastructure as a Code」の文化を浸透させることで実現しています。

photo

 具体的なツールとしては、HashiCorpの「Terraform」を使っています。

 Terraformは、GCPやAWSなどのクラウドサービスを抽象化して、宣言的にコードとしてインフラのあるべき状態を記述することで、その状態になるようにプロビジョニングを実行してくれます。

 各マイクロサービスごとのTerraformのコードの管理やそのコードの自動アプライを実現するために、microservices-terraformというリポジトリを準備しています。

photo

 このリポジトリにはStarter-kitというTerraformのモジュールも提供されています。これを使うことでマイクロサービスをリリースするための最低限必要なインフラを簡単に構築できるようになっています。

 最低限必要なインフラとは、さっき紹介したNamespaceやGCPプロジェクトがあり、またモニタリングの設定だったり、それらをStarter-Kitを使って一発でブートストラップできます。

 開発者はまず自分たちでTerraformのコードを書いて、このリポジトリにプルリクエストをかけます。

 インフラの経験が少ない開発者がいきなりTeraformのコードをがりがり書くのは難しいので、われわれマイクロサービスプラットフォームチームがレビューを行います。レビューが通ってマージが行われると、CIが走ってプロビジョニングが行われるというフローになっています。

photo

開発者が自分たちでインフラのプロビジョニングができるように

 このワークフローで問題になるのは、マイクロサービスプラットフォームチームによるレビューのところです。Terraformのコードを保守していくためにはレビューは必須なのですが、マイクロサービスが増えれば増えるほどここがボトルネックになってスピードが失われてしまいます。

 これを解決するためにGitHubのCODEOWNERSという機能を使います。

 CODEOWNERSを使うとリポジトリの特定のディレクトリにコードオーナーを指定できます。コードオーナーはプルリクエストのアプルーブやマージができます。

 この機能を使ってGitHubの各サービスの専用ディレクトリに、各サービスのチームメンバーをコードオーナーとしてアサインします。すると、自分たちのサービスに関するプルリクエストは自分たちでアプルーブしてマージできるわけです。

 つまり、何度かわれわれマイクロサービスプラットフォームチームのレビューを受けて、自分たちでTerraformのコードを書く自信が付いたら、自分たちでレビューしてスピード感を持って進めればいいし、まだちょっと不安があるチームはわれわれのレビューを受けて、書き方を覚えてもらう、ということをやっています。

 この仕組みはとてもうまく回っていて、いまではこのリポジトリに110名ものコントリビュータがいます。これはどういうことかというと、100名以上の開発者が自分たちでインフラのプロビジョニングをしているということです。

photo

 1年前、インフラの管理ができるのはSREの10名くらいしかいませんでした。そこから10倍以上の成長です。

 この変化は、マイクロサービスプラットフォームチームがもたらした大きなものだといえます。

デプロイのパイプラインも開発者が作る

 次はサービスのデプロイです。

 マイクロサービスではデプロイも、開発者が自分たちで行います。このために「Spinnaker」というツールを使っています。

 SpinakerはNetflixがオープンソースとして公開した継続的デリバリのためのツールです。

 Spinnakerは例えば、カナリアデプロイメントを行うステージ、Blue/Greenデプロイメントを行うステージ、デプロイの承認を行うステージなど、さまざまなステージを提供しています。開発者はサービスの特性に合わせたステージを組み合わせてデプロイを行うことができます。

photo

 すでにSpinnakerを使い始めて1年ですが、60以上のパイプラインが作られています。

 これはSpinnakerの設定画面です。開発者はこの画面を通じてデプロイの設定をしています。ただ、これはGUIなので、ここが開発者のペインポイントになっていました。

photo

 GUIは小規模なチームが素早く動くには便利だと思うのですが、チームがスケールするほど変更したときのレビューができないとか、ドキュメント化するのがむずかしいとか、ほかのチームの設定をコピーして使うことができないといった問題があります。

 これを解決するためSpinnakerにもInfrastracture as Codeへの移行をはじめています。

 具体的には「Kubernetes v2 Provider」というSpinnakerの機能を利用しています。これはKubernetesのYAMLを直接書く方式です。つまりKubernetesのYAMLさえも開発者に書いてもらおうという方向に進んでいます。

 これもTerraformと同様にGitHubにプルリクエストを送ってレビューをする方法を採用しています。

 この仕組みは導入したばかりですが、GUIの設定の負担を減らして、かつ、Kubernetesの設定であるYAMLファイルを覚えることで、開発者が自分たちにとってよりよいKubernetesの設定をカスタマイズできるようになるのではないかと期待しています。

 以上が、この1年のわれわれマイクロサービスプラットフォームチームが取り組んできたことです。

【次ページ】 マイクロサービスプラットフォームチームが「これから」取り組もうとしていること

開発総論 ジャンルのセミナー

開発総論 ジャンルのトピックス

開発総論 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!