EKS AutoModeを使ったSelf-serviceの導入

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社hacomono / u-kai

メンバー / インフラエンジニア / 従業員規模: 101名〜300名

最終更新日2026/01/29投稿日2026/02/03

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

EKS AutoMode

EKS AutoModeの基本機能のみ(Capabilitiesは未使用)

10名以下

2025年7月

B to B

B to C

利用プラン	EKS AutoMode
利用機能	EKS AutoModeの基本機能のみ(Capabilitiesは未使用)
ツールの利用規模	10名以下
ツールの利用開始時期	2025年7月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

EKS AutoMode を採用することで、マネージド領域を増やしつつ、EKS on Fargate では実現できない DaemonSet などの柔軟なワークロード運用を可能にしている。
開発/ステージング/本番環境はそれぞれ独立した EKS クラスターを用意しているが、プロダクトは 1 つのクラスターで namespace ごとに分離し、クラスターの運用コストを抑えている。
Crossplane と Argo CD を組み合わせることで、マネージドサービス含めあらゆるリソースを GitOps によってデプロイ可能し、以下を達成している。
- プラットフォームエンジニアリングにおけるSelf-service
- GitリポジトリをSSoTとした一貫した運用/開発体験
GitOpsのソースはモノリポを採用し、基盤構成をコードから容易に把握できるようにしつつ、Code Ownerによって権限を分離することで自由かつ安全にコード変更を可能にしている。
プロダクト毎のアプリケーションコードに関してはマルチリポを採用し、他プロダクトに影響なく開発できるようにしている。
OSSのLGTMスタックを利用することで大量のテレメトリーデータを低コストかつ高速に処理できている。低コストのため、収集されるテレメトリーデータの量が予測しにくい基盤構築初期段階においても安心してテレメトリーデータを収集できている。
OpenTelemetryを利用することで、現在hacomonoで利用しているDatadogやマネージドサービスへの移行を容易にしている。
OpenTelemetryのk8sattributes processorを利用し、テレメトリーデータにKubernetesリソース特有のリソース属性を自動付与し、検索性を上げている。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

弊社では、"hacomono"というプロダクトを提供しており、今後は hacomono 以外にも多くのプロダクトを提供するマルチプロダクトを展開予定。しかし、現状の仕組みや体制だとプロダクトごとに一からリソースを整備/運用していく必要があり、プロダクトの増加に伴って以下のような懸念がある。

開発速度
- プロダクトごとにリソースを一から整備する必要があり、時間がかかる懸念
セキュリティの担保
- セキュリティ設定の抜け漏れやヒューマンエラーが発生する懸念
運用コスト
- プロダクト数の増加に伴って基盤チームの運用コストが増加し、基盤チームの負荷が高まる懸念

そこでプラットフォームエンジニアリングの考え方を取り入れ、共通基盤を構築することで上記課題を解決しようと考えた。

どのような状態を目指していたか

共通基盤を構築し、以下を達成することでマルチプロダクト展開を遂行できるようにしたい。

開発者が実施すべきことを最小化し、開発速度やセキュリティを担保できる状態
プロダクト数が増えても運用コストを抑えられる状態

そこで Self-service の実装や一貫した運用体験を実現を目指した。

比較検討したサービス

Amazon ECS
AWS Lambda (弊社はほとんどのケースでAWSを利用しているため、他パブリッククラウドのマネージドKubernetesサービスは検討せず)

比較した軸

少ない開発工数で運用がスケールする基盤を開発可能かどうか
Self-service を達成できるかどうか
技術に関する情報やエコシステムが豊富かどうか

選定理由

エコシステムが豊富かつあらゆるリソースを一貫した Kubernetes API で運用可能なところ
Self-service を達成するためのエコシステムや仕組みが存在しているところ
- ECSでSelf-serviceを達成するにはベンダー独自の仕組みに依存するか独自の仕組みを構築する必要があると判断
プラットフォームエンジニアリングのデファクトスタンダードの一つで、事例や情報が多いところ
EKS AutoMode の提供が開始され、従来の EKS よりもマネージドな領域が増えたところ

導入の成果

Crossplane と Argo CD の組み合わせによって、manifest を記述するだけで必要なリソースが提供できるようになり、Self-service を達成した。
上記 Self-service によって複雑な構成を抽象化したことで、開発者が実施すべきことを最小化し、開発速度やセキュリティを担保できる状態を実現した。
- 開発者がリソース作成のために必要な manifest や Terraform などの IaC 記述量が大幅に削減された。
GitOps を採用することで一貫した開発/運用体験を得ることができた。
その他プロダクトに必要な横断的機能(オブザーバビリティ/モニタリング/サービス間通信制御など)もエコシステムの導入によって解決できる見込み。
Self-service によってプロダクト数が増加しても基盤チームの運用コストが大幅に増加しないことが見込まれている。

導入時の苦労・悩み

Kubernetesおよびエコシステムの技術調査/導入/運用に工数がかかっている点
Kubernetes manifests のコードレビューや検証が難しい点
現時点では基盤を構築することに集中しており、基盤利用者獲得に注力しきれていない点

導入に向けた社内への説明

上長・チームへの説明

導入に向けて PoC を実施し、Self-service の必要性や有用性を説明した。
他サービスよりもKubernetesやエコシステムを利用したSelf-service構築事例が多く、優位であることを説明した。
Kubernetes ベースがうまくいかずとも、他コンテナサービスやサーバレスへの移行が可能であることを説明した。

上長からのフィードバック

カスタムリソース実装によるリソース作成の抽象化は、複雑な構成を少ない作業で達成できるため、開発者の認知負荷や作業工数の削減が期待できる。
一方、リソース作成の抽象化に加えて開発者の認知負荷を下げる取り組みは続ける必要がある。(CLI ツールや UI の提供など)
サーバレスとは違い常時インフラ費用が発生するため、多くのプロダクトが本基盤を利用しなければ価値が低くなってしまう。多くのプロダクトに利用してもらうようにすることが重要。

活用方法

よく使う機能

Kubernetes の基本機能
様々なエコシステム
- Argo CD
- Crossplane
- Istio
- LGTM スタック
- OpenTelemetry Operator
- External-DNS
- External Secrets

ツールの良い点

EKS AutoMode の良い点

Karpenter や CNI、Node などがマネージドされており設定や運用を行う必要がないところ
Fargate とは異なり、DaemonSet を利用できるところ

Kubernetes 全般の良い点

エコシステムが豊富であらゆるリソースを一貫したインターフェイスで運用可能なところ
宣言的かつ回復力が高いインフラ管理が可能なところ

Argo CD の良い点

GitOps による一貫した開発/運用体験を提供できるところ
AppProject による権限管理が容易なところ
UI が充実しており、Kubernetes に不慣れな利用者でも操作しやすいところ

Crossplane の良い点

マネージドサービス含むあらゆるリソースを Kubernetes API で一貫して運用可能なところ
カスタムリソースを定義することで、利用者の認知負荷を下げられるところ

ツールの課題点

EKS AutoMode の課題点

Capabilities を今後利用していきたいが、現状は以下のようにupstream との完全な互換性がなく利用に踏み切れないこと
- Argo CDの認証手段が限定的
- luaスクリプトによるArgo CDのカスタム処理が利用不可
- Argo CD Applicationで展開できるリソースにQuotaが存在
監査ログやオブザーバビリティ周りの実装が CloudWatch ベースであり、OpenTelemetry への統合に工数がかかること。また、CloudWatchを利用することで利用費が高くなってしまうこと。