こんにちは、かたいなかです。
6/28に行われたJAWS-UGコンテナ支部 #19にて転職会議でのEKSの導入事例について話してきました。
この記事では、登壇時に解説した内容をスライドに書ききれなかったことも交えつつ紹介します。
EKS化以前の転職会議のECS基盤の課題
転職会議では上記のような課題を抱えていました。
いくつかはECSおよび周辺ツールの最新の機能を使うことでも解決できるのですが、転職会議ではサービス専属でコンテナに詳しいSREが複数名いたこと、またエンジニア組織として「チャレンジを尊ぶ文化」であったこともあり、EKSでの新基盤構築にチャレンジすることになりました。
EKS移行をどう進めたか
EKS化にあたってはいくつかの大きな方針を決めてすすめることにしました。
マイクロサービスごとの切り替え
マイクロサービスごとにECSクラスタに向いていたRoute53のレコードを順次EKSクラスタに向けることで切替を進めました。
これにより切り戻しを可能にしながら小さい単位で着実に移行していくことができました。
フェーズを分けて漸進的にすすめる
EKSクラスタの機能を本番運用に耐える状態まで高めていくための作業についてはいくつかのフェーズに分けて順番に進めることにしました。
これによりKubernetesのエコシステムの膨大な選択肢に圧倒されて移行が進まなくなることを防げたと考えています。
開発者への知識移転
開発者への知識移転に関しては重点的に取り組みました。これは、新しいEKS基盤が「SREのための基盤」ではなく「アプリケーション開発者のための基盤」となることを目指していたからです。
実際、丁寧に知識移転を行ったことで、のちにEKS移行完了後のさらなる改善の一部をアプリケーションエンジニアが主導しはじめるなど、アプリケーションエンジニアが主体的に活動できる基盤づくりにつながったと考えています。
転職会議のEKS基盤
実際に構築したのは以下のような基盤です。
CI/CD
CI/CDのツールとしてはFluxを採用しています。
ChatOpsのツールと合わせ、大きく以下の３つのユースケースで使えるようにしています。
- 新しいイメージのタグでステージング環境を自動で更新
- 特定のブランチから作られたイメージをChatOpsでステージングにデプロイ
- 本番にChatOpsで新しいイメージをデプロイ
監視
DatadogのエージェントをKubernetesクラスタ上にインストールし、Kubernetesのメトリクスを取得できるようにしています。
DatadogのAutoDiscovery機能を使い、システムコンポーネントのPrometheusエンドポイントからのメトリクスの取得も行っており、これによりAWS LoadBalancer Controller等のエラーも検知できるようにしています。
ログ
ログ管理にはS3を保存先にしたGrafana Lokiを使用しています。
保存先がS3であることもあり、CloudWatch Logs等より費用的に安くなるのが選定理由です。
ECS/EKSメリデメ
ECSでもEKSでもできること
最近ではECSの機能の充実に伴い、コンテナオーケストレーションに必要な多くのことがECSでもEKSでも行えるようになってきています。
EKSのメリット
EKSクラスタの構築の自由度およびKubernetesの開発者フレンドリーなUXにより、開発者が自立して動ける基盤を作りやすいのが利点と考えています。
転職会議ではアプリケーション開発者がKubernetes周りの改善を実施したりするなど、SREの人数が限られた組織での運用改善に威力を発揮しています。
ECSのメリット
EKSで気をつけること
Podを安全に終了する
Podを安全に終了できるよう、以下のことは行っておきましょう。
参考: Kubernetes: 詳解 Pods の終了 - Qiita
STSのリージョナルエンドポイントを使う
以前、私の個人ブログの記事で紹介したように、リージョナルエンドポイントを使用しない場合に定期的にAWS SDKを使う箇所のパフォーマンスが悪化する場合があるため、環境変数等でリージョナルエンドポイントを使用するように設定しましょう。
システムコンポーネントの監視
以前、私の個人ブログの記事でも紹介したようにシステムコンポーネントの導入時には監視まで考えておく必要があります。転職会議では導入したいコンポーネントからメトリクスが取得できなかったりする場合、PRをだしてPrometheusエンドポイントを生やしてもらう等の対応を行ったりしています。
まとめ
EKSクラスタの構築をやりきることで運用上の大きなメリットを享受できることを実感しています。一方で闇雲にEKSを選択するのではなく、システムや開発組織の状態からECSでスピーディにコンテナベースのシステムを構築するのが合理的になる場面は多々あると考えています。
また、先に分散トレーシングを導入する等、他のタスクとの優先度付けを慎重に考えた上でEKS導入に取り組むのが良いと考えています。
主な質疑応答
EKSのクラスタのアップグレードはどのように行っていますか？
- インプレースアップグレードで行っています。
EKSクラスタは何で管理しているか？
- Terraformで管理しています。
Istioは使っていないのですか？
- SREが2名しかいないため、現在のところは運用コストも加味して導入していません。
Argo Workflow実際使ってみての感触は？
- 最近になって特定のバッチ処理同士を同時実行させないセマフォ機能等、かなり細かい制御ができるようになってきたので良さそうに感じています。
ECSとEKSどちらを導入したらよいか
- 完全にケースバイケースになると思います。転職会議ではアプリケーション開発者のコンテナの知識を段階的に高めていくために、EC2 => ECS => EKSと段階を踏んで進めてきました。
