検索
特集

「インフラ怖い」が生んだSREの業務負担――freeeはどう改善したか運用コストを減らす3つのポイントとは(2/2 ページ)

本番環境にKubernetesを活用するfreeeでは、SREに運用管理業務が集中して疲弊してしまった。そこで、開発チームにサービスの運用管理業務を任せることで改善していったという。その方法とは?

Share
Tweet
LINE
Hatena
前のページへ |       

改善させるために取り組んだこと

 足立氏は、このような状況から、SREに集中する運用管理業務の負担を改善するため、EC2とEC2 Auto Scalingでサービスを構築、運用するのではなく、コンテナ化されたアプリケーションを運用するようにした。具体的には、アプリケーションのコンテナ化には「Docker」(参考記事)、コンテナ化されたアプリケーションの実行環境として「Kubernetes」(参考記事)を導入。インフラ構成をコードで管理するため「Terraform」を採用し、「インフラ構成のコード化」(Infrastructure as Code)にも取り組んだ。

 Terraformはインフラ構築ツールの一つだ。クラウドサービスの構成定義に主眼を置き、構成ファイルの記述内容に基づいてTerraformが自動で環境を構築し、構成変更があれば、Terraformが定義された内容に構成を変更する機能を持つ。インフラ構成をコード化することで、バージョン管理して扱うことができ、さらに、そのコードを基にインフラを再利用できる。

 freeeでは、AWSが提供するリソースを、Terraformの定義ファイルを基に構築することで、SREが行っていたネットワーク構築や環境整備を自動化した。さらに、インフラ構成のコード化を機に、各開発チームに担当するサービスのインフラ運用を任せることにしたという。

Terraformを用いてAWSの各サービスをコードで構築、運用する形に
Terraformを用いてAWSの各サービスをコードで構築、運用する形に

 「現状のインフラ構成は、Terraformの定義ファイルに書かれたコードから把握できる。そこで、開発者にもインフラ構築の権限を与え、担当するサービスのインフラ構成を変更する場合は、Terraformの定義ファイルを編集し、編集したファイルをSREがレビューして反映させるというフローに切り替えた。インフラを触るのは怖いという状況は変わらないかもしれないが、SREがレビューするという点が加わったことで、インフラ構築や運用に対するハードルが下がった」

TerraformとGitHubとCI(継続的インテググレーション)ツールの「CircleCI」を用いてAWS環境を構築、運用するフロー
TerraformとGitHubとCI(継続的インテググレーション)ツールの「CircleCI」を用いてAWS環境を構築、運用するフローにした

 講演後半、足立氏は「Kubernetes on AWS」を活用して構築していた7つのプロダクトを「Amazon EKS(Amazon Elastic Kubernetes Service)」に移行させた経験から、コンテナ化されたアプリケーションをKubernetesで運用する際、SREの負担を減らす3つのポイントを紹介した。それぞれ見ていこう。

  • シングルテナントによる運用
  • Kubernetesはアプリケーション実行環境という認識を持つ
  • サービスの交換をやりやすい状態に保つ

シングルテナントによる運用

 足立氏は、Kubernetesでコンテナ化されたアプリケーションを実行する場合、1つのクラスタで複数のプロダクトを管理する「マルチテナント」ではなく、1つのプロダクトまたは分離したい権限ごとにクラスタを分割する「シングルテナント」を推奨した。

全てのプロダクトを1つのクラスタで管理するのではなく、プロダクトごとにクラスタを立ち上げる方式を推奨した(画像下)
全てのプロダクトを1つのクラスタで管理するのではなく、プロダクトごとにクラスタを立ち上げる方式を推奨した(画像下)

 シングルテナントのメリットは3つある。

 1つ目は、障害の影響範囲(Blast radius)が小さくなるため、リスクを分散し、安心感を高められることだ。もし、Kubernetes本体にバグがあったり、運用ミスが発生したりしても影響はクラスタ内のプロダクトのみでサービス全体への影響を回避できる。

 2つ目は、セキュリティの境界線を明確化できることだ。シングルテナントなら、仮想マシン(VM)レベルでサービスが分割されるため、権限を管理しやすくできる。

 3つ目は、SREがKubernetesクラスタ全体に関係するアップデート作業をしやすいことだ。マルチテナントの場合、Kubernetesのアップデートに失敗したときは全てのサービスでロールバックする必要があるなど対応コストがかかる。シングルテナントであれば、このコストを減らすことができる。

 シングルテナントのデメリットについて、足立氏はKubernetes環境の利用料金や運用コストが増える点を挙げたが、運用コストについては「freeeでは開発者に権限を移譲して運用してもらったように、コストを分散させることができる」とした。

 ただし、開発チームがKubernetesのアップデートをはじめ、さまざまなライブラリのアップデートをいきなり運用していくのは難しいので、freeeでは横断的に各クラスタとサービスに対応するチームを新設して対応しているという。

 「Kubernetesが発展途上な部分もあり、深い知識がないと対応できない課題もあるのが現状だ。もし、私たちのように開発陣に運用を任せる場合、SREが対応する場面が必ずある。マネージドサービスを積極的に利用してシステムにKubernetesを組み込み、より良いサービスが出てきたときに取り込みやすい状態にしておくというマインドで、負担を増やさないような開発基盤の構築を試みるべきだろう」

クラスタの運用コストを下げるため、Kubernetesと他のマネージドサービスを組み合わせて運用することと(左)、今後新しいマネージドサービスが登場して取り込むことを念頭に置き、システムを設計することを推奨した(右)

 ところで、新しいチームを作って開発チームがクラスタ管理することを支援するとはいえ、開発チーム視点に立って考えてみれば、Kubernetesのクラスタ運用を突然任せられるというのは負担であり、拒否反応を示したのではないか。講演終了後の足立氏に、いきなり運用を任せて大丈夫だったのか、伺ってみた。

 足立氏は「確かに拒否される可能性があった。私たちも開発チームにシングルテナント化を提示する際は、SREが今まで通りクラスタの運用管理をし続ける選択肢も含めた。だが、開発陣が自主的にKubernetesの運用を負担すること(シングルテナント化)を選択してくれた。もともと、開発陣がKubernetesに興味があったから選んでくれたのだろう」と答えた。

 新しい知識に興味関心を持ち続ける開発者の意識も、SREの業務負担の軽減に一役買ったのかもしれない。

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
[an error occurred while processing this directive]