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

　次はDevOps文化の醸成です。

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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