Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スタンバイにおけるECS on Fargateから EKS on Fargateへ移行した話

スタンバイ
November 05, 2021
1.4k

スタンバイにおけるECS on Fargateから EKS on Fargateへ移行した話

スタンバイ

November 05, 2021
Tweet

More Decks by スタンバイ

Transcript

  1. 自己紹介  吉田 芳弘 ◦ Senior Site Reliability Engineer 

    技術 ◦ AWS ◦ Scala  興味 ◦ DevOps(開発速度向上) 2
  2. アジェンダ  概要 ◦ 移行の計画 ◦ EKS on Fargateを選んだ理由 ◦

    既存システムとの結合 ◦ 切替方法 ◦ 今後の展望  まとめ 6
  3. スタンバイのシステム概要 9  以下の3大機能 ◦ 求人を集める ◦ 求人を提供する ◦ 広告を配信する

     全てAWS上にあり、ほと んどがECS/Fargate  常時100台前後のコンテナ が稼働 求人を集める 求人を提供する 広告を配信する
  4. 達成したいことは何か? デリバリーパフォーマンスを上げていきたい ◦ デプロイの頻度(特に) ◦ 変更のリードタイム ◦ MTTR(特に) ◦ 変更失敗率


    Source:Google Cloud, Google Cloud で実行されている DevOps 組織の有効性を評価する
 https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora 14
  5. マイクロサービスの他に代替案はなかったか?  kubernetesにしたら解決する課題が多かった ◦ 環境(staging,production)ごとにDocker Imageを別々に生成している ◦ 共通で使っているSideCarをupdateするのが大変 ◦ Service

    Mesh を使ったカナリアリリース、サーキットブレーカーの導入 ◦ 変更失敗率を下げたい ◦ etc... ▪ 作り込めば解決はできるが、我々のチームとしては、マネージドで解決できるならマネージドにしたい 18
  6. EKS on Fargateを選んだ理由  スタンバイのサービスはECS on Fargateで動いている ◦ EC2と違ってインスタンスのことを考慮に入れないでscalingをしていたので、また新 しい仕組みを考えて実装するのはコストがかかる

    ◦ あとでFargateにしようとすると、そこでまた新しい仕組みを考える必要がある  ダメだったらEC2にしよう ◦ 試しにやってみるかという軽い気持ちだった 25
  7. 既存システムとの結合 51 検証環境 本番環境 TOBE feature branch base開発だっ たので、この形 に

    code repositoryが複数ある ため、dispatchで別の Github Actionsを叩くよう にして共通化 git tagで指定した ものをpullしてき て別のECRに詰 め替え
  8. まとめ  ジャーニーの結果 ◦ デリバリーパフォーマンスを計測する土台を作成することができた ◦ 開発速度向上のための施策がしやすくなった  導入を検討している人に向けて ◦

    「モノリスからマイクロサービスへ」は読んだ方が良い ◦ ログやメトリクスは今のシステムのまま行けるのか先に調査することがおすすめ 59
  9. メンバー募集しています!  人々の「はたらく」をアップデートしていく仲間を募集しています。  「株式会社スタンバイ エンジニア 求人」で検索 61 ソフトウェアエンジニア 広告エンジニア

    検索エンジニア SRE データエンジニア 機械学習エンジニア QAエンジニア フロントエンドエンジニア モバイルアプリエンジニア サーチクオリティ エンジニアリングマネージャー CTO室/プロジェクトマネージャー CTO室/組織運営担当