目次
NewsPicksの共通バックエンドサーバーの進化を支えるECS
参考になった
2
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
株式会社ユーザベース / Takumi Iino
メンバー / SRE / 従業員規模: 1,001〜5,000名
最終更新日投稿日
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 51名〜100名 | 2022年 | B to B B to C |
| ツールの利用規模 | 51名〜100名 |
|---|---|
| ツールの利用開始時期 | 2022年 |
| 事業形態 | B to B B to C |
アーキテクチャ
アーキテクチャの意図・工夫
アーキテクチャ図の実線のリソースはIaC管理のリソース、破線のリソースはデプロイ時に作成されるリソースです。ECSの場合、ECSクラスターやキャパシティプロバイダまではIaC管理しています。ECSクラスターで動くECSサービス、ECSサービスが利用するタスク定義などは動的に作成、変更するためIaC管理はしていません。
- ChatOpsによるリリース
- Slack Botにメンションすることで誰でもサービスのリリース可能です。
- 誰がいつリリースしたかのログがチャット上に残り便利です。
- 全体リリース前にCanaryでの動作確認が可能
- Canaryに事前にデプロイてE2Eテスト実行と動作確認が行えるようにしています。
- 動作確認を待ってから全体にリリースします。ここでロールバックも行えます。
- ECS on EC2を利用して性能とコストを両立させる
- 性能とコストの両立が必要な共通バックエンドサーバーではECS on EC2を利用しています。
- EC2とFargateではEC2の方がコストパフォーマンスが良いです。
- Spotインスタンスも利用可能です。（開発では常にSpotインスタンスを使っています）
- 引き換えに設計の考慮事項、セキュリティの考慮事項、運用コスト、プロビジョニング速度などが犠牲になります。
- ECSタスク定義を調整し、1つのECSタスクが1つのEC2インスタンスを占有するようにしています。
- これが1インスタンスでのリソースの無駄や過剰なEC2インスタンスの確保の回避が目的です。
- 性能とコストの両立が必要な共通バックエンドサーバーではECS on EC2を利用しています。
- FargateとFargate Spotの併用で可用性とコストを両立させる
- 複数台起動する常駐ワーカーについてはFargateとFargate Spotを併用しています。
- リソース（SQSなど）をポーリングして処理を行う常駐のバッチを常駐ワーカーと呼んでいます。
- EC2時代の資産を有効活用するため、Lambda化などは行わずECSサービス（ECSタスク）として動かしています。
- 常駐ワーカーはタスク数が減ってもユーザー影響が少ないため、中断のリスクと引き換えにコスト削減を行います。
- 複数台起動する常駐ワーカーについてはFargateとFargate Spotを併用しています。
- 常駐ワーカーと定期実行ワーカーの実行環境の共有
- 常駐ワーカーはECSサービスとして実装しています。
- 定期実行ワーカーはEventBridgeイベントで起動するECSタスクとして実装しています。
- 具体的にはStep FunctionsのステートマシンからECSタスクを起動しています。
- 同時実行の制御、タイムアウトなどはステートマシン側で制御しています。
- ともにECSタスクとして起動するため、コンテナイメージ、ネットワーク設定、実行Roleなどが共有できます。
- これにより開発コスト、メンテナンスコストを削減することができます。
- CPUアーキテクチャに応じたイメージの取得
- コンテナイメージがマルチCPUアーキテクチャに対応している場合、タスク定義のCPUに応じたコンテナイメージを利用してくれます。
- FargateであればX86_64とARMの切り替えをタスク定義のCPUの設定変更だけで行えます。
- EC2の場合はキャパシティプロバイダーで確保するEC2インスタンスのインスタンスタイプ変更も必要です。
- Farget SpotがARMをサポートしていない間（〜2024/9）は、共通バックエンドサーバーはARM、常駐ワーカーはX86_64と二つのCPUアーキテクチャを並行稼働させていました。
- コンテナイメージがマルチCPUアーキテクチャに対応している場合、タスク定義のCPUに応じたコンテナイメージを利用してくれます。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
NewsPicksでは2022年から段階的にサービスの本番環境をAWSのマネージドサービス（ECS）に移行してきました。 移行前はマネージドサービスは利用しておらず、レガシーな構成で運用を行っていました。
- 共通バックエンドだけでもEC2インスタンスが100台以上存在しており、インフラに対する認知負荷、作業負荷がとても高い状態でした。
- 開発者自身がインフラの設定変更を行うことが難しく、毎回SREへの作業依頼が発生ており、リードタイムの悪化や、開発者がオーナーシップを持つことが難しくなっていました。
- インフラの設定がコード管理されていないため、影響調査が必要以上に難しくなっていました。
- EC2インスタンスを気軽に更新できる状態になっておらず、定期的な更新が難しい状態となっていました。
どのような状態を目指していたか
運用コストの削減とシステム構成を継続的に改善できる状態を目指していました。
- AWSのマネージドサービスを利用して運用コストを削減する
- ログをサーバー外で一元管理・参照できる状態にする（CloudWatch Logs, S3）
- EC2インスタンスのメンテナンスやEOLの対応コストをなくす
- アプリケーションに必要な最低限のリソースで運用可能にする
- セキュリティ対応範囲を限定し、バージョンアップを楽にする
- インフラの設定が全てコードで管理する
- インフラの影響調査を可視化し、変更のリードタイムを短くする
- 開発環境の増設など、開発者のニーズに合わせた横展開を容易にする
- オートスケーリングなどサービス運用に適した自動化が行える
- システム構成を継続的に改善できる状態にする
比較検討したサービス
- Amazon Elastic Kubernetes Service
- ECSでコンテナオーケストレーションの要件を十分満たせているため採用しませんでした。
導入の成果
改善したかった課題はどれくらい解決されたか
- firelensを利用してログをサーバー外で一元管理できる様になりました。
- ECS最適化AMIを利用することでECSで利用するEC2インスタンスの運用がほぼなくなりました。
- ECSサービス、ECSタスクの構成変更が容易になり、リソースの最適化が行えました。
- インフラの設定が全てコード管理されることで、変更の影響範囲調査が容易になりました。
- 構成変更のリードタイムも短くなりました。
どのような成果が得られたか
- 誰でも安心安全にリリースできるようになりました。
- リリースに伴うトラブルが激減しました。
- 非エンジニア（主にデザイナー）も共通バックエンドサーバーをリリースするようになりました。
- リリース回数が増えました。1日10回リリースされる日も珍しくなくなりました。
- リリースに伴うトラブルが激減しました。
- 共通バックエンドサーバーのECSに移行後も継続的に改善を行うことができました。
- コストとパフォーマンスの両立を求めECS on FargateからECS on EC2へ移行
- 常駐ワーカーをECSサービスへ移行、定期実行ワーカーをStepFunctionを利用してのECSタスクへの移行
- 全部入りコンテナをサブシステム別コンテナに変更
- サブシステム別コンテナを個別のECSサービスに分割
- CPUアーキテクチャをX86_64からARMへ移行
- FargateとFargate Spot, EC2 OnDemandインスタンスとEC2 Spotインスタンスの併用
導入に向けた社内への説明
上長・チームへの説明
インフラ構成が複雑なことが原因でリリース時に様々なトラブルが発生していたため、マネージドサービスへの移行は急務でした。
活用方法
よく使う機能
- 既知のアクセス数の変化に対応するScheduled Actionでのオートスケーリング
- 通勤時間帯やお昼など既知のアクセス数の変化に対応するため、定期でオートスケーリングを実施しています。
- DeploymentConfigurationによるきめ細かいタスク入れ替え指定
- ローリング更新デプロイメントを採用しているのですが、対象システムの特性に応じたきめ細かい設定を行っています
- 共通バックエンドサーバーはmaximumPercentを150%に制限しています。
- 初期化処理（DB接続、起動時のキャッシュ作成）による負荷のスパイクを回避するのが目的です。
- 複数台が並列稼働している常駐ワーカーもmaximumPercentを150%に制限しています。
- 起動リクエストの集中が原因でSpotインスタンスの確保が失敗してしまう問題を回避するのが目的です。
- 一度に1タスクだけが起動していることを期待する常駐ワーカーはminimumHealthyPercentを0%, maximumPercentを100%にしています。
- この設定により旧タスクを停止してタスク数が0になった後に新タスクが起動します。
- それ以外のワーカーについてはmaximumPercentを200%に設定しています。
- firelensでのログ転送
- アクセスログなどが膨大になるためサイドカーのfluentdにログを転送し出力先の制御を行っています。
- CloudWatch Logsへはエラーログのみ転送し、他はS3に保存しています。
- ECS Execでのリモート接続＆リモートデバッグ
- 開発環境ではECS Execの有効化とデバッグ用ポートの解放を行っています。
- 実行中のコンテナ上でのコマンド実行やリモートデバッグが容易に行えます。
- 2025/09からAWSマネジメントコンソール上でECS Execが実行可能になり、より利便性が増しました。
ツールの良い点
- ECSのプラットフォームバージョンの変更が少なく安定しています
- ECS最適化AMIを利用することでECS on EC2でもインタンス管理コストをほぼ0にできます。
- キャパシティプロバイダを変更するだけで性能、可用性とコストの両立が行えます。
- ネットワーク設定などについてはEC2での運用知識がそのまま転用できます
- リソース（SubnetやSecurity Group）の共用も可能です。
- ECSサービス、タスクの構成変更が容易です。
ツールの課題点
ECS on EC2を採用した場合、Fargateと比較してさまざまなオーバーヘッドが発生します。
- EC2インスタンスの確保が必要なため、Fargateと比べ数分起動が遅いです。
- EC2インスタンスのメモリを全てECSタスクで利用することはできません。
- ECSタスクに割り当て可能なメモリは85%程度になります。
- これはホストとなるEC2インスタンスでdockerやssm-agentなどが動作しているのが理由です。
- 具体的な数値はインフラストラクチャのコンテナインスタンスで確認できます。
今後の展望
Amazon ECS Managed Instancesの検討
2025/09/30にAmazon ECS Managed Instancesが発表されました。現時点ではECS on EC2とくらべコスト面で不利なためすぐに移行はできない認識をしています。（EC2を直接利用する場合と比べ追加コストが発生する、ドキュメントでSpotインスタンスへの言及がない、など） しかし、最新のCPUを利用できるなどの利点もあるため、現在Fargateを利用しているシステムで検証しつつ、適切なタイミングで移行できればと考えています。
株式会社ユーザベース / Takumi Iino
メンバー / SRE / 従業員規模: 1,001〜5,000名
よく見られているレビュー
株式会社ユーザベース / Takumi Iino
メンバー / SRE / 従業員規模: 1,001〜5,000名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法