[20210617 そろそろマネージド、クラウドネイティブで行こう! コンテナサービスへの移行祭り]Pairs, PairsエンゲージにおけるECS Fargateの移行・活用事例

© 2021 eureka, Inc. All Rights Reserved.
Pairs,Pairsエンゲージにおける
ECS Fargateの移行・活用事例
そろそろマネージド、クラウドネイティブで行こう!
~コンテナサービスへの移行祭り~
2021年 6月17日

View Slide

About Me
masashi.yamamoto (@marnie0301)
● 株式会社エウレカ
○ Head of SRE
● 守備範囲
○ インフラ構築〜監視運用、セキュリティ対応、必要に応じ
てプログラムの修正やパフォーマンス最適化etc..

View Slide

Agenda
● EC2からECS on Fargateに全面的に移行した話
○ 移行当時の背景（提供サービス・Webシステム構成)
○ 現在の利用状況・ユースケース
○ 移行当時(2019年)の課題感
○ 技術選定・検討〜設計
■ 実運用・利用コンポーネントの紹介
○ 振り返り

View Slide

© 2021 eureka, Inc. All Rights Reserved. 4
恋活・婚活マッチングアプリオンライン結婚相談所サービス
真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け
Pairsは日本で最も使われている恋活・婚活
マッチングアプリ
日本人特有の交際相手探し、恋愛に対する障壁を和らげ
るために設計
24時間365日オペレーターが待機し公的身分証明書の
確認、お問い合わせ、パトロール監視に対応
登録からお相手の紹介まで全てスマホで利用可能
プロのコンシェルジュチームによる24時間サポート
毎月20名(紹介10名+検索10名)のお相手候補
出典：MMD研究所xスマートアンサー「2020年マッチングサービス・アプリの利⽤実態調査」より  

View Slide

© 2021 eureka, Inc. All Rights Reserved. 5
日本最大規模の累計登録者数 

View Slide

● 累計登録会員数が1000万人以上の国内最大級マッチン
グアプリ『ペアーズ』が、1年以内に結婚したい人のために、
手頃で始めやすい結婚相談所をつくりました。
● 登録から顔合わせの実施まで、オンラインで完結できま
す。
● 専属コンシェルジュチームが婚活を手厚くサポート
Pairsエンゲージについて
6

View Slide

現在のECS Fargateの利用状況・ユースケースの紹介
● 全社システム構成の8割以上はECS Fargateを利用
○ 数値ベース
■ クラスタ数は100~300程度
■ 利用Task数はピーク時間帯だと400~
○ AWS Lambda,APIGatewayなどのServerlessコンポーネントで対応が難しい場合は、ほぼECS Fargateを採用。
○ 適用ユースケース
■ WebFrontサーバー,APIサーバー
■ Batchタスク
○ 適用外の例
■ 独自のクラスタ内ライフサイクルとステートを持つElasticsearch
■ wordpress
■ 一部社内システム
■ GPU,HiSpecなCPUが必要などのFargateで対応不能な物

View Slide

移行検討当時(2018/12)のWebシステムの構成
● 3-Tier Infra Structure
● Immutable Infrastrctureの実践
○ Packer+AnsibleでGolden Imageを作成
○ terraformで配布

View Slide

移行検討当時(2018/12)の課題感
● VMの更新にかかる時間と手間が大きかった。
○ Packer Build … (10分ほど経過)
■ Playbookが肥大化・秘伝のタレ化
○ terraformでauto scaling groupのamiを差し替える (1~2分)
○ 手動でauto scaling 台数を操作して新旧を浸透させていく(台数依存 5~15分)
○ そもそも、小さな修正を入れたいだけなのに上記のようなイメージを焼き直すコストがつらい
● ふとしたところで影響が出て更新が大掛かりになることがある
○ いろいろ混ざってる他のレシピに影響を与えないかなどがみえづらい
○ playBookの一部のRoleが腐って他にも影響が出るから交換ができない...
● 学習コストが高いので、移譲もしづらい
○ それがなくても、Ansible,Packer,Terraform,AutoScalingの操作方法と一連のフローの理解が必要
変更・交換容易性が低い = 開発アジリティが失われる

View Slide

コンテナのメリット
● コンテナの以下の特性をメリットと捉える
○ 小さく作れる事
■ 小さなデプロイが可能になる
○ 独立性
■ 盛り盛りのVMでたまに困るモジュールやミドルウェアのバージョン衝突や相互影響の回避
○ 交換/廃棄容易性
■ 廃棄しやすく作る(例えば状態を持たない)事で最大限のメリットを受けられる
● 以前はVM交換で対応していたような事がアプリケーションのデプロイのような感覚で交換可能
● デプロイの度に旧コンテナの廃棄と新規コンテナが起動がされるので、Immutable Infraしやすい
○ 起動と廃棄が高速
■ スケールアウト速度の向上

View Slide

移行検討(2018/12) ~課題の解決検証
● Packer Build の手間とansible playbookの肥大化・修正の相互影響
○ 複数コンテナを組み合わせる形式に移行する事で、変更したいコンテナ（役割）に対してのみ変更が可能。
○ コンテナを小分けにする事で一つ一つのビルド時間が短縮される
● ミドルウェア同士の依存の衝突・影響など
○ 役割別で分ける事で更新による依存の衝突などを最小にできる。（実質避けられる)
● AutoScalingの上げ下げの手間
○ AWSのコンテナオーケストレーターに合わせてデプロイパイプラインを構築すれば不要になる
● 学習コストと移譲のしづらさの問題
○ terraform+ansible+packerの学習が不要になる。
○ 開発者はdockerfileのみ変更すれば良い
概ね解決可能＋新しいメリットも享受できる

View Slide

移行検討 ~結論
コンテナ移行まったなし

View Slide

実際の移行タイムライン
● 移行計画
○ およそ(?) 3Month * 1member で基盤部分とPairs1カ国目の移行を実施
○ 1Month * 1memberで横展開(2,3カ国目,他サービスなど)
● 計画策定
○ 技術選定前調査
■ ECS,EKS,コンテナ周辺技術の情報収集 / 1Week
■ EKS 構築〜テスト運用 / 2Week
■ ECS Fargate構築〜テスト運用 / 2Week
■ ECSを利用する事を決定しての全体設計 / 1~2Week
○ 実移行作業
■ VM Image to Docker Images,環境変数お引越し / 1~2Week
■ Logging/Monitoring設計・実装 / 2Week
■ デプロイパイプラインの変更・設計 / 2Week
■ テスト/DNS向き変えによる移行と経過観察/オートスケール調整 (2~4Week 実働は2~3day程度)

View Slide

技術選定(2018年12月当時)
● 候補
○ Docker on EC2
○ EKS
○ ECS on EC2
○ ECS on Fargate
● 選定の基本方針
○ 少人数かつ、インフラ構築以外のタスクも数多く担当しているので、できるだけ管理する物を少なくしたい
○ 継続的に向き合う事になるので、できる限り運用の工数や自前の努力を少なくしたい

View Slide

結論(2019年1月当時)
● Amazon ECS on Fargateの採用を決定
○ 自社のリソースをよりプロダクトに集中できる
■ 管理工数の削減
● クラスタ運用が無い。EC2が完全に不要
● ホストOSのお守りが不要
■ AWSのサービスの中でもかなりアップデート頻度が盛ん
● 便利な機能を自社のリソースを使わず利用しやすい
■ AWSの他のサービスとの連携や作り込みが容易である
● SSM Parameterの呼び出し
● CodeDeployとの連携が容易+B/Gデプロイ可能
● AutoScalingなどとの連携も容易

View Slide

結論補足(2019年1月当時)
● EKS については試験運用を一部システムで２週間ほど回していたが、移行検討
当時は以下の理由で見送り。
○ リリースしたてだったので、DataPlane側の構築で自前でやらないといけ
ない事が多かった。(IAM,logging,SSMParameter,etc…)
○ 当時はFargateがなかった。
○ ECSと比べて後発のサービスだった為、当時は他のAWSサービスとの連
携がECSより遅れていた。
● 2021年6月現在は大分足回りも整ってきた印象+Fargateもある
○ 現在の材料で同じ判断をしたかは分からない。
○ 一部経緯などでEKSを利用しているコンポーネントもあるが、システム全
体面での大きな移行の必要性は感じていない。

View Slide

設計・構築の基本方針
● コンテナの有用性をできる限り享受できるように設計やベストプラクティスを取り入れていく
○ Twelve Factor App
■ モダンなWebアプリケーションを実現するベストプラクティス
■ コンテナに限らないベースとしての重要な設計指針
○ Docker Development / Docker File Best Practice
■ コンテナ毎に１つのプロセスだけ実行 (なるべく小さく)
■ コンテナはエフェメラル(短命)であるべき(廃棄可能であること)
■ イメージレイヤを最小に、不要なものを置かない、etc…
○ NIST SP800-190
■ コンテナ利用において守るべきセキュリティ標準
● 既存のAWSサービスとできる限り連携して自前のメンテナンスコストを省く

View Slide

コンテナの設計/運用方針①
● 一つ一つのコンテナを小さく作る
○ デプロイの粒度を小さくできるように
○ 依存衝突などを避けられるように
● 状態をもたない
○ エフェメラルな状態を保てること
● コンテナへの更新は廃棄・再生成によってのみ行う。
○ 反映フローを統一できる
○ 変更・切り戻しの考慮事項を少なくできる

View Slide

コンテナの設計/運用方針②
● イメージサイズを小さく保つ
○ 軽量イメージの採用
○ 余計な物をイメージに含まない
■ 例えば画像のようなサイズが大きいものはCDN(CloudFront)+ObjectStorage(s3)に移行する
● 基本的に外部から依存を注入する
○ ポータビリティの確保(Twelve Factor App III の実践)
○ SSM Parametrer,SecrertManager

View Slide

デプロイパイプライン
● ChatApp+CodeBuild+CodeDeploy Blue/Green
○ 内部的にはLBのtargetGroupの切り替え
○ codeDeployの提供機能なので、簡単な設定で実現可能
○ デプロイ時のversion混在を避けられる
○ green保持期間（0分~設定可能)は切り戻しが高速。
○ codeCommit,codePipeLine連携でリリース自動化も可能。
● 今までAnsible+Packer+terraformで行っていたVM運用の消滅
○ アプリケーションのデプロイと同じ方法で更新可能
○ 移譲のしやすさの向上

View Slide

スケーラビリティの担保
● CloudWatchAlarmを使ったcpu utilization の値ベースで自動スケールアウト/スケールイン
○ その時点の負荷に即して必要な量のリソースを適切に活用できるので、コスト削減にも役に立つ
○ 複数ルールを組み合わせて、負荷の上昇幅に応じて増減をコントロール。
○ fargate起動速度やオートスケールのcoolDown,評価間隔など、短期の変動に対する限界はある。
○ 実績ベースでは、scheduledと複数ルールの組み合わせで1日の中で5倍以上ワークロードが動的に上下しつつ、
trafficをさばけている。
図1. ある時間帯における Task数遷移

View Slide

セキュリティ
● 基本的な指針や考え方
○ NIST SP800-190 を前提におく
● ECR Registry Scanの活用
○ ECR Push ~ チケット起票までを自動化
● その他に外部・OSSセキュリティスキャンツール
を併行して検証・運用中

View Slide

ロギング / モニタリング
● logging
○ stdout,errに出すだけでcloudwatchに転送される
○ 基本的にsshしなくても済むようにログ収集を整備
○ 一部Alert発火などに関連するlogはdatadogAgentに転送
● monitoring / alert
○ Datadog agentの取得したメトリクスを確認
■ コンテナ単位でのメトリクス取得が可能。
○ cpu,memory,alb latency,alb_target _5xx,4xx等の指標を
watch
■ 監視については、WebサービスならWebサービスに必要
な監視をすれば良いだけであまり変わらない。

View Slide

コンテナ(ECS Fargate)移行・運用をしてみての振り返り
● 当初課題に抱えていたVMの更新容易性の低さやデプロイ粒度の大きさを解決できた。
■ 交換にかかっていた工数の削減
■ terraform,ansible,packerなどの技術伝達なくdockerと対象ミドルウェアの知識さえあれば修正・追加が移譲できるように
なったので、開発者に任せられる範囲が広がりお互いhappyに。
■ VM総入れ替えではなく、コンテナ単位のリリースに移行されリリース単位を小さくする事が実現された
■ appliccation developer, infra developer 双方にとって快適なので、以降の新規構築ではスタンダード化された。
● 2019移行当時に比べ情報・導入事例も増えているので、より導入+知見共有を社内にもしやすくなってきている
○ https://ecsworkshop.com/

View Slide

まとめ
● EC2からECS on Fargateに全面的に移行した話
○ 移行当時の背景（提供サービス・Webシステム構成)
○ 現在の利用状況・ユースケース
○ 移行当時(2019年)の課題感
○ 技術選定・検討〜設計
■ 実運用・利用コンポーネントの紹介
○ 振り返り

View Slide


View Slide

[20210617 そろそろマネージド、クラウドネイティブで行こう! コンテナサービスへの移行祭り]Pairs, PairsエンゲージにおけるECS Fargateの移行・活用事例

[20210617 そろそろマネージド、クラウドネイティブで行こう! コンテナサービスへの移行祭り]Pairs, PairsエンゲージにおけるECS Fargateの移行・活用事例

marnie0301

More Decks by marnie0301

Other Decks in Technology

Featured

Transcript