足立氏は、このような状況から、SREに集中する運用管理業務の負担を改善するため、EC2とEC2 Auto Scalingでサービスを構築、運用するのではなく、コンテナ化されたアプリケーションを運用するようにした。具体的には、アプリケーションのコンテナ化には「Docker」(参考記事)、コンテナ化されたアプリケーションの実行環境として「Kubernetes」(参考記事)を導入。インフラ構成をコードで管理するため「Terraform」を採用し、「インフラ構成のコード化」(Infrastructure as Code)にも取り組んだ。
Terraformはインフラ構築ツールの一つだ。クラウドサービスの構成定義に主眼を置き、構成ファイルの記述内容に基づいてTerraformが自動で環境を構築し、構成変更があれば、Terraformが定義された内容に構成を変更する機能を持つ。インフラ構成をコード化することで、バージョン管理して扱うことができ、さらに、そのコードを基にインフラを再利用できる。
freeeでは、AWSが提供するリソースを、Terraformの定義ファイルを基に構築することで、SREが行っていたネットワーク構築や環境整備を自動化した。さらに、インフラ構成のコード化を機に、各開発チームに担当するサービスのインフラ運用を任せることにしたという。
「現状のインフラ構成は、Terraformの定義ファイルに書かれたコードから把握できる。そこで、開発者にもインフラ構築の権限を与え、担当するサービスのインフラ構成を変更する場合は、Terraformの定義ファイルを編集し、編集したファイルをSREがレビューして反映させるというフローに切り替えた。インフラを触るのは怖いという状況は変わらないかもしれないが、SREがレビューするという点が加わったことで、インフラ構築や運用に対するハードルが下がった」
講演後半、足立氏は「Kubernetes on AWS」を活用して構築していた7つのプロダクトを「Amazon EKS(Amazon Elastic Kubernetes Service)」に移行させた経験から、コンテナ化されたアプリケーションをKubernetesで運用する際、SREの負担を減らす3つのポイントを紹介した。それぞれ見ていこう。
足立氏は、Kubernetesでコンテナ化されたアプリケーションを実行する場合、1つのクラスタで複数のプロダクトを管理する「マルチテナント」ではなく、1つのプロダクトまたは分離したい権限ごとにクラスタを分割する「シングルテナント」を推奨した。
シングルテナントのメリットは3つある。
1つ目は、障害の影響範囲(Blast radius)が小さくなるため、リスクを分散し、安心感を高められることだ。もし、Kubernetes本体にバグがあったり、運用ミスが発生したりしても影響はクラスタ内のプロダクトのみでサービス全体への影響を回避できる。
2つ目は、セキュリティの境界線を明確化できることだ。シングルテナントなら、仮想マシン(VM)レベルでサービスが分割されるため、権限を管理しやすくできる。
3つ目は、SREがKubernetesクラスタ全体に関係するアップデート作業をしやすいことだ。マルチテナントの場合、Kubernetesのアップデートに失敗したときは全てのサービスでロールバックする必要があるなど対応コストがかかる。シングルテナントであれば、このコストを減らすことができる。
シングルテナントのデメリットについて、足立氏はKubernetes環境の利用料金や運用コストが増える点を挙げたが、運用コストについては「freeeでは開発者に権限を移譲して運用してもらったように、コストを分散させることができる」とした。
ただし、開発チームがKubernetesのアップデートをはじめ、さまざまなライブラリのアップデートをいきなり運用していくのは難しいので、freeeでは横断的に各クラスタとサービスに対応するチームを新設して対応しているという。
「Kubernetesが発展途上な部分もあり、深い知識がないと対応できない課題もあるのが現状だ。もし、私たちのように開発陣に運用を任せる場合、SREが対応する場面が必ずある。マネージドサービスを積極的に利用してシステムにKubernetesを組み込み、より良いサービスが出てきたときに取り込みやすい状態にしておくというマインドで、負担を増やさないような開発基盤の構築を試みるべきだろう」
ところで、新しいチームを作って開発チームがクラスタ管理することを支援するとはいえ、開発チーム視点に立って考えてみれば、Kubernetesのクラスタ運用を突然任せられるというのは負担であり、拒否反応を示したのではないか。講演終了後の足立氏に、いきなり運用を任せて大丈夫だったのか、伺ってみた。
足立氏は「確かに拒否される可能性があった。私たちも開発チームにシングルテナント化を提示する際は、SREが今まで通りクラスタの運用管理をし続ける選択肢も含めた。だが、開発陣が自主的にKubernetesの運用を負担すること(シングルテナント化)を選択してくれた。もともと、開発陣がKubernetesに興味があったから選んでくれたのだろう」と答えた。
新しい知識に興味関心を持ち続ける開発者の意識も、SREの業務負担の軽減に一役買ったのかもしれない。
Copyright © ITmedia, Inc. All Rights Reserved.