KINTOのコンテナ化環境の選定と現状

参考になった

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

KINTOテクノロジーズ株式会社 / 島村純平

EM / インフラエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名

最終更新日2025/09/11投稿日2025/09/11

ツールの利用規模	事業形態
301名〜500名	B to C

ツールの利用規模	301名〜500名
事業形態	B to C

アーキテクチャ

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

上記はパッケージングのうち、コンテナを使ったアプリケーション環境の標準設計。Sandbox環境では、上記のよくあるパターンをセルフサービスで作成できるような仕組みを準備している(AutoProvisioning)。実構築の際は、必要に応じてRedisやその他コンポーネントを追加する。コスト削減を主軸とする場合は、コンポーネントの削除や諸々の施作を実施する。

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

導入背景

入社時にはすでにECSがメインとなっており、一部EC2が残っている状態でしたので、ヒアリングなどで補完していることをご承知おきください。

ツール導入前の課題

EC2上にアプリケーションを構築していたので、リリースに手間がかかる
EC2の運用に負荷がかかっている
(当時はアクセスは少なかったと思うが)スケーリングなどの問題
開発環境と本番環境で依存ライブラリのバージョンや構成が異なり、動作しないことがある
複数のアプリケーションが同じサーバー上で異なるバージョンのライブラリを必要とし、競合が発生する
新しい開発者が環境構築に時間を要する

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

クラウドネイティブなインフラ

比較検討したサービス

Amazon EKS (Amazon Elastic Kubernetes Service)
- 当時はOnFargateかOnEC2。AutoModeなし。

比較した軸

PlatformGroupの運用負荷
デプロイなどアプリケーション部門の運用負荷、認知負荷
ナレッジの多さ

選定理由

■ECSの良い点

CICDなどのデプロイをGitHubActionsで行なっているが公式でActionsがある
ややこしいManifest、APIのバージョン管理などを考慮しなくていい
そこそこ簡素な設定でスケーリングその他を行うことが容易である

■EKSでの懸念

全体的に、EKSだと習熟までのコストが高い
アプリケーション担当者の習熟コストも高い
責任分解点などを考慮した運用設計が難しい
現時点でのインフラ規模の場合、EKSのCluster分割を考慮してもコストメリットが見えない

導入の成果

改善したかった課題はどれくらい解決されたか

現時点でメンテナンス用以外のEC2はほぼ存在しなくなった
- Lambdaも合わせて使用しているが、サーバレスを主軸として活用
環境構築もパッケージングし、構築依頼を受けてから３営業日程度での提供を実現している
CICDの標準設計を行うことで、アプリケーションを動かすところまでのリードタイムが短縮

どのような成果が得られたか

リリース頻度が増えた
- リリース時の手順が不要になることでのコスト低減
- リリースの時間短縮
インフラ担当の障害対応頻度の低減(タスクの自動復旧による)
ECRとも組み合わせて、社内的な脆弱性ルールを満たす仕組みを提供

導入時の苦労・悩み

一部のプロダクトについては、onEC2からの移行支援を行ったが、コンテナの特徴である

可搬性
不変性

まわりを考慮したアプリケーション改修に苦労した。導入自体についてはそんなにハレーションも起きずに、問題はなかった認識。

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

上長・チームへの説明

初期のころと違う、内製を行うにあたってのクラウドネイティブ環境の必要性を説明したことと、開発体制が変わってきたタイミングであったことから、導入についての反対意見はなかったと聞いた。

活用方法

よく使う機能

サーバレス(onFargate)

OnEC2も可能だが、基本的にはFargate上で動かすことが推奨されている認識
Dev/StgまではFargateSpotで、ProdはFargate設定で稼働。社内ではARM64アーキテクチャを推奨
- 費用面で、AMD64より安価になる
- 昔よりはARM64だとSpotで起動しやすい、確保しやすいというイメージはない

タスク数の柔軟な変更

Devは最低起動数を１としてコストを低減している
アプリケーション部門に、ここの設定権限を委譲してIaCから外すことでインフラ運用から除外
- ピークが事前にわかる場合や、負荷が上がってきた場合の設定はアプリケーション運用で行う
夜間など動かさない場合は、Task起動数を0にしてコストを落とす

RunTask (バッチ運用)

バッチはEventBridgeから呼び出す形でECSで行うことが多い
- Lambdaの場合は、時間制限があるため
RunTaskだと、複数のTaskが起動する場合がある(仕様)
呼び出しが成功したがTaskが起動しない場合はリトライされない(仕様)
- 改善としてStepFunctions経由で呼び出すように変更した

ツールの良い点

必要十分の機能がある
複雑なコンポーネントがなく理解しやすい
- 定義ファイルなど
CodePipelineやGitHubActionsとのIntegrationが容易
EKSと違って責任分解点を設定しやすい
- 単純にCluster/Serviceまではインフラ
- Task定義はアプリケーション
- インフラ管理部門がいる場合、この部分は重要になると思う
2024/09からFargeteSpotでARM64アーキテクチャをサポートしたので、さらに安価に動かせる

ツールの課題点

昔はTaskが落ちた原因の表示が短時間
- 理由を確認するために意図的にデプロイ失敗を起こすことが多かった
- 今は長期ログを出力するよう改善
BlueGreenDeploymentを行う際に、CodeBuild以外の場合は実装がややこしい(External)
- GitHubActionsで実装したが、使う手順が煩雑になることなどもあり、利用頻度が上がらなかった
- 最近は新しい組み込みが出たらしいが、まだ未検証
サーバレスの場合、K8sでいうDaemonSetがないので、ログやメトリクス転送の場合はサイドカーにするかサービスを別に立てて転送するなどの設計が必要

ツールを検討されている方へ

AWSでWEBサービスとしてのコンテナを動かす場合は、基本的にはECS一択で良いと思う。K8sについては、技術者として色々と満足できると思うが、運用負荷などを考慮すると、K8s(EKS)が必須な要件がなければ、ECSを選ぶことをお勧めする。最初はConsoleから設定し、LogなどはCloudWatchLogsで十分だが、Fluentbit (Firelens)が使えるので、要件や環境に応じて転送を行うように段階的に使うのがわかりやすいと思う。