LIVESENSE ENGINEER BLOG

リブセンスエンジニアの活動や注目していることを発信しています

JAWS-UGコンテナ支部 #19 で転職会議でのEKS導入事例について話してきました

f:id:katainaka0503:20210610173653p:plain こんにちは、かたいなかです。

6/28に行われたJAWS-UGコンテナ支部 #19にて転職会議でのEKSの導入事例について話してきました。

jawsug-container.connpass.com

この記事では、登壇時に解説した内容をスライドに書ききれなかったことも交えつつ紹介します。

EKS化以前の転職会議のECS基盤の課題

f:id:katainaka0503:20210628132741j:plain

転職会議では上記のような課題を抱えていました。

いくつかはECSおよび周辺ツールの最新の機能を使うことでも解決できるのですが、転職会議ではサービス専属でコンテナに詳しいSREが複数名いたこと、またエンジニア組織として「チャレンジを尊ぶ文化」であったこともあり、EKSでの新基盤構築にチャレンジすることになりました。

EKS移行をどう進めたか

EKS化にあたってはいくつかの大きな方針を決めてすすめることにしました。

マイクロサービスごとの切り替え

マイクロサービスごとにECSクラスタに向いていたRoute53のレコードを順次EKSクラスタに向けることで切替を進めました。

これにより切り戻しを可能にしながら小さい単位で着実に移行していくことができました。

f:id:katainaka0503:20210610143608j:plain

フェーズを分けて漸進的にすすめる

EKSクラスタの機能を本番運用に耐える状態まで高めていくための作業についてはいくつかのフェーズに分けて順番に進めることにしました。

これによりKubernetesのエコシステムの膨大な選択肢に圧倒されて移行が進まなくなることを防げたと考えています。

f:id:katainaka0503:20210610143617j:plain

開発者への知識移転

開発者への知識移転に関しては重点的に取り組みました。これは、新しいEKS基盤が「SREのための基盤」ではなく「アプリケーション開発者のための基盤」となることを目指していたからです。

実際、丁寧に知識移転を行ったことで、のちにEKS移行完了後のさらなる改善の一部をアプリケーションエンジニアが主導しはじめるなど、アプリケーションエンジニアが主体的に活動できる基盤づくりにつながったと考えています。

f:id:katainaka0503:20210610143622j:plain

転職会議のEKS基盤

実際に構築したのは以下のような基盤です。

CI/CD

CI/CDのツールとしてはFluxを採用しています。

ChatOpsのツールと合わせ、大きく以下の3つのユースケースで使えるようにしています。

  • 新しいイメージのタグでステージング環境を自動で更新
  • 特定のブランチから作られたイメージをChatOpsでステージングにデプロイ
  • 本番にChatOpsで新しいイメージをデプロイ

f:id:katainaka0503:20210610144120j:plain f:id:katainaka0503:20210628132917j:plain

監視

DatadogのエージェントをKubernetesクラスタ上にインストールし、Kubernetesのメトリクスを取得できるようにしています。

DatadogのAutoDiscovery機能を使い、システムコンポーネントのPrometheusエンドポイントからのメトリクスの取得も行っており、これによりAWS LoadBalancer Controller等のエラーも検知できるようにしています。

f:id:katainaka0503:20210610144136j:plain f:id:katainaka0503:20210628133851j:plain

ログ

ログ管理にはS3を保存先にしたGrafana Lokiを使用しています。

保存先がS3であることもあり、CloudWatch Logs等より費用的に安くなるのが選定理由です。

f:id:katainaka0503:20210610144149j:plain f:id:katainaka0503:20210610144153j:plain

ECS/EKSメリデメ

ECSでもEKSでもできること

最近ではECSの機能の充実に伴い、コンテナオーケストレーションに必要な多くのことがECSでもEKSでも行えるようになってきています。

f:id:katainaka0503:20210610144300j:plain

EKSのメリット

EKSクラスタの構築の自由度およびKubernetesの開発者フレンドリーなUXにより、開発者が自立して動ける基盤を作りやすいのが利点と考えています。

f:id:katainaka0503:20210610144308j:plain

転職会議ではアプリケーション開発者がKubernetes周りの改善を実施したりするなど、SREの人数が限られた組織での運用改善に威力を発揮しています。

f:id:katainaka0503:20210610165216j:plain

ECSのメリット

f:id:katainaka0503:20210610165021j:plain

EKSで気をつけること

Podを安全に終了する

Podを安全に終了できるよう、以下のことは行っておきましょう。

f:id:katainaka0503:20210610164630j:plain

参考: Kubernetes: 詳解 Pods の終了 - Qiita

STSのリージョナルエンドポイントを使う

以前、私の個人ブログの記事で紹介したように、リージョナルエンドポイントを使用しない場合に定期的にAWS SDKを使う箇所のパフォーマンスが悪化する場合があるため、環境変数等でリージョナルエンドポイントを使用するように設定しましょう。

f:id:katainaka0503:20210610164607j:plainf:id:katainaka0503:20210610164611j:plainf:id:katainaka0503:20210610164615j:plain

システムコンポーネントの監視

以前、私の個人ブログの記事でも紹介したようにシステムコンポーネントの導入時には監視まで考えておく必要があります。転職会議では導入したいコンポーネントからメトリクスが取得できなかったりする場合、PRをだしてPrometheusエンドポイントを生やしてもらう等の対応を行ったりしています。

f:id:katainaka0503:20210628173002j:plain f:id:katainaka0503:20210610164549j:plain

まとめ

EKSクラスタの構築をやりきることで運用上の大きなメリットを享受できることを実感しています。一方で闇雲にEKSを選択するのではなく、システムや開発組織の状態からECSでスピーディにコンテナベースのシステムを構築するのが合理的になる場面は多々あると考えています。

また、先に分散トレーシングを導入する等、他のタスクとの優先度付けを慎重に考えた上でEKS導入に取り組むのが良いと考えています。

f:id:katainaka0503:20210610170133j:plain

主な質疑応答

  • EKSのクラスタのアップグレードはどのように行っていますか?

    • インプレースアップグレードで行っています。
  • EKSクラスタは何で管理しているか?

    • Terraformで管理しています。
  • Istioは使っていないのですか?

    • SREが2名しかいないため、現在のところは運用コストも加味して導入していません。
  • Argo Workflow実際使ってみての感触は?

    • 最近になって特定のバッチ処理同士を同時実行させないセマフォ機能等、かなり細かい制御ができるようになってきたので良さそうに感じています。
  • ECSとEKSどちらを導入したらよいか

    • 完全にケースバイケースになると思います。転職会議ではアプリケーション開発者のコンテナの知識を段階的に高めていくために、EC2 => ECS => EKSと段階を踏んで進めてきました。

参考資料