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

Transcript

1. スタンバイにおけるECS on FargateからEKS on Fargateへ移行した話 2021年11月04日 1
2. 自己紹介
   吉田 芳弘 ◦ Senior Site Reliability Engineer
   技術 ◦ AWS ◦ Scala
   興味 ◦ DevOps(開発速度向上) 2
3. 会社紹介
   社名：株式会社スタンバイ（https://stanby.co.jp/）
   代表：南 壮一郎
   所属人数：207名（2021年10月1日時点）
   沿革：2019年11月、Zホールディングス株式会社と株式会社ビズリー チ（現ビジョナル株式会社）との合弁事業会社として設立
   ミッション：UPDATE WORKSTYLES 「はたらく」にもっと彩を 3
4. サービス紹介 求人検索エンジン「スタンバイ」
 https://jp.stanby.com/ 取扱求人数：1000万件以上
 （2020年8月時 点） CM公開中https://jp.stanby.com/cm 4
5. 今日の話題
   移行の計画から実際に移行するまでのジャーニー ◦ 導入を検討している方への礎になれれば ◦ 執筆時点のバージョンの話になりますので、後に修正されている可能性がありま す 5
6. アジェンダ
   概要 ◦ 移行の計画 ◦ EKS on Fargateを選んだ理由 ◦ 既存システムとの結合 ◦ 切替方法 ◦ 今後の展望
   まとめ 6
7. それでは いってみよう 7
8. 8 移行の計画
9. スタンバイのシステム概要 9
   以下の3大機能 ◦ 求人を集める ◦ 求人を提供する ◦ 広告を配信する
   全てAWS上にあり、ほと んどがECS/Fargate
   常時100台前後のコンテナ が稼働 求人を集める 求人を提供する 広告を配信する
10. EKS/Fargate移行対象 10
    全て一気に移行は危険な ので、frontとweb-apiを対 象にした
    よく使われるメインの機 能なので、課題や不具合 を早く発見できることを 期待 移行対象 移行対象 求人を提供する
11. 移行の計画 11 マイクロサー ビスの他に代 替案はなかっ たか？ 達成したいこ とは何か？ 移行中に起き た出来事
12. 移行の計画 12 マイクロサー ビスの他に代 替案はなかっ たか？ 達成したいこ とは何か？ 移行中に起き た出来事
13. 達成したいことは何か?
    デリバリーパフォーマンスを上げていきたい 13
14. 達成したいことは何か? デリバリーパフォーマンスを上げていきたい ◦ デプロイの頻度(特に) ◦ 変更のリードタイム ◦ 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
15. 移行の計画 15 マイクロサー ビスの他に代 替案はなかっ たか？ 達成したいこ とは何か？ 移行中に起き た出来事
16. マイクロサービスの他に代替案はなかったか？
    前提 ◦ エンジニアの人数が今後急拡大する予定 ◦ デリバリーパフォーマンスを計測して上げていきたい ▪ 自動計測するためには、現在のシステムの変更、及び何かしらのツールの作成が必要 16
17. マイクロサービスの他に代替案はなかったか？
    MTGをおこなった ◦ 弊社のサービスが抱えている課題を出す ◦ それに対するソリューションを出す ◦ グループ化する 17 例:
18. マイクロサービスの他に代替案はなかったか？
    kubernetesにしたら解決する課題が多かった ◦ 環境(staging,production)ごとにDocker Imageを別々に生成している ◦ 共通で使っているSideCarをupdateするのが大変 ◦ Service Mesh を使ったカナリアリリース、サーキットブレーカーの導入 ◦ 変更失敗率を下げたい ◦ etc... ▪ 作り込めば解決はできるが、我々のチームとしては、マネージドで解決できるならマネージドにしたい 18
19. マイクロサービスの他に代替案はなかったか？
    ただ、いつかは移行したいという意見は一致したが、今すぐ移行する かは、エンジニアの意見が全員一致はしなかった ◦ 今後のスタンバイの事業拡大を考慮し、会社全体で移行を決定し、全面的にコ ミットして取り組むことに 19
20. 移行の計画 20 マイクロサー ビスの他に代 替案はなかっ たか？ 達成したいこ とは何か？ 移行中に起き た出来事
21. 突然ですが、 皆さんは 御存知でしょうか? 21
22. 「モノリスから マイクロサービスへ」という書籍を！ 22
23. 移行中に起きた出来事
    書籍に書いていることが実際に起きました！ ◦ 1ヶ月ぐらいたったときに、チームのメンバーから何で移行するんだっけ? ◦ 調査したいことが無限に出てくる ◦ etc…
    書籍のまわし者ではないのですが、移行を検討する前に読了しておく ことをおすすめします 23
24. 24 EKS on Fargateを選んだ理由
25. EKS on Fargateを選んだ理由
    スタンバイのサービスはECS on Fargateで動いている ◦ EC2と違ってインスタンスのことを考慮に入れないでscalingをしていたので、また新 しい仕組みを考えて実装するのはコストがかかる ◦ あとでFargateにしようとすると、そこでまた新しい仕組みを考える必要がある
    ダメだったらEC2にしよう ◦ 試しにやってみるかという軽い気持ちだった 25
26. EKS on Fargateの課題
    DaemonSetが利用できない
    Podの起動が（場合によっては）遅い
    SecurityGroupPolicy未対応 26
27. EKS on Fargateアップデート 27
28. 28 既存システムとの結合
29. 既存システムとの結合 29 メトリクス ログ CD
30. 既存システムとの結合 30 メトリクス ログ CD
31. 既存システムとの結合(ログAS-IS) 31
32. 既存システムとの結合(ログAS-IS) 32 ECSの情報やサー ビス名を取得して 設定している error logだけ Datadogに送信して slack通知をしている
33. EKS on Fargateに変えてい きたい 33
34. 今できていることはでき るようにしたい 34
35. そんなに甘くない 35
36. 既存システムとの結合(ログ)
    EKS on Fargateでサービスの情報が取れない ◦ fluentbitのFilter(Kubernetes)が動かず、コンテナ情報が取れていない ▪ issue(https://github.com/aws/containers-roadmap/issues/1197) 36
37. 既存システムとの結合(ログTO-BE) 37
38. 既存システムとの結合(ログTO-BE) 38 cloudwatch logsのlog groupには サービス名が出る。 subscription filterで後続に接続で きるようにした
39. 既存システムとの結合 39 メトリクス ログ CD
40. 既存システムとの結合
    ASIS ◦ Datadog Agent、Datadog Trace Agent、Datadog Integrationを使って様々なメト リクスを取得 40
41. 既存システムとの結合
    kubernetesのCluster情報が追加で欲しい ◦ Datadog Cluster Agentを入れればOK? 41
42. そんなに甘くない 42
43. 既存システムとの結合
    Datadog Cluster Agentが基本的にはDaemonsetが前提 ◦ install guide
    Podとしても動かせるとはドキュメントに書いてある ◦ Helmのvalue値を色々調整して動かしました 43
44. 既存システムとの結合 44 メトリクス ログ CD
45. 既存システムとの結合 45 CodeBuildで ECRにpush 検証環境 ecspressoで Fargateに deploy CodeBuildでECR にpush 本番環境 ecspressoで Fargateにdeploy ASIS
46. 既存システムとの結合
    既存のシステムにも課題がある ◦ 本番環境でもbuildをしている ◦ deployをする前にe2e testの実行を行っていない ▪ pull request merge前に行っている ◦ DockerImageがlatest運用されている 46
47. どこまで一度に変更する か 47
48. 今できていることはでき るようにしたい 48
49. 既存システムとの結合
    既存のdeployフローはそのままに、別のdeployフローを作成 ◦ e2e test実行は一旦そのまま ◦ 別のdeployフローにすることによって、切り戻しができるようにした
    Github ActionsとArgoCDでdeployフローを作成し、GitOpsの形に 49
50. 既存システムとの結合 50 検証環境 本番環境 TOBE
51. 既存システムとの結合 51 検証環境 本番環境 TOBE feature branch base開発だっ たので、この形 に code repositoryが複数ある ため、dispatchで別の Github Actionsを叩くよう にして共通化 git tagで指定した ものをpullしてき て別のECRに詰 め替え
52. 52 切替方法
53. 切替方法 53
54. 切替方法 54 weightを変更するだけで切り替 えられるようにした これによって切り戻しも簡単に
55. 55 今後の展望
56. 今後の展望
    今回変更したのは一部のサービスだけ ◦ まずは横展開できるように運用してみてあがってきた課題を修正 56
57. 今後の展望
    デリバリーパフォーマンスの可視化
    Blue Green Deployment、カナリアリリース
    検証環境、QAテスト環境、負荷テスト環境を素早く増やす or リクエ ストをバイパスできる環境を用意することによって開発速度の向上
    etc... 57
58. 58 まとめ
59. まとめ
    ジャーニーの結果 ◦ デリバリーパフォーマンスを計測する土台を作成することができた ◦ 開発速度向上のための施策がしやすくなった
    導入を検討している人に向けて ◦ 「モノリスからマイクロサービスへ」は読んだ方が良い ◦ ログやメトリクスは今のシステムのまま行けるのか先に調査することがおすすめ 59
60. まとめ
    まだまだ改善したいことは山積み！！
    我々の旅はつづく... ◦ @yoshihir_jp ◦ @ryota_hnk ◦ 大橋 香菜子 ◦ 小宮 孝二 ◦ ki38sato 60
61. メンバー募集しています！
    人々の「はたらく」をアップデートしていく仲間を募集しています。
    「株式会社スタンバイ エンジニア 求人」で検索 61 ソフトウェアエンジニア 広告エンジニア 検索エンジニア SRE データエンジニア 機械学習エンジニア QAエンジニア フロントエンドエンジニア モバイルアプリエンジニア サーチクオリティ エンジニアリングマネージャー CTO室／プロジェクトマネージャー CTO室／組織運営担当