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

リーンな開発を目指す第一歩_デブサミ2022_18C3 / Our first step for LSD

mirai_miyata
February 22, 2022

リーンな開発を目指す第一歩_デブサミ2022_18C3 / Our first step for LSD

mirai_miyata

February 22, 2022
Tweet

Other Decks in Technology

Transcript

  1. ©2022 Mirai Translate, Inc. ⾃⼰紹介 2 2 名前 宮⽥ 周(Shu

    Miyata) ニックネーム ein 所属 株式会社みらい翻訳 役割 アプリケーションエンジニア 趣味 ゲーム / 料理 @miyagon000v
  2. ©2022 Mirai Translate, Inc. 3 株式会社みらい翻訳 企業向けクラウドAI⾃動翻訳 Mirai Translator •

    ⾼い翻訳精度(TOEIC 960点〜) • ⾼いセキュリティ(ISO27001/ISO27017) • ユーザー視点でのUX ® VISION ⾔語の壁を超え、新しい⽣活と仕事の様式をもたらす共通語の機能 を機械翻訳として2028年までに作る。 (世界のすべての⼈々に英語を⺟語とする⼈々と同じ体験を与える)
  3. ©2022 Mirai Translate, Inc. リーン開発とは︖ • 開発プロセスからムダをなくし、 ⾼速に開発すること なぜリーン開発をしたい︖ •

    リーンスタートアップに基づき、 ⾼速に仮説検証したい 6 リーン開発 アイデア サービス 構築する データ 計測する 学ぶ
  4. ©2022 Mirai Translate, Inc. 私たちの現状と理想 7 現状 理想 デプロイ頻度 1回/週

    開発リードタイム(設計〜リリース) 1週間〜1ヶ⽉以上 デプロイ頻度 1回/⽇ 開発リードタイム(設計〜リリース) 1⽇〜1週間 =理想よりも開発スピードが遅い︕
  5. ©2022 Mirai Translate, Inc. 競合開発が多い • Mirai Translatorは複数チームで開発している • チーム間での競合開発が多発している

    • リリースタイミングの調整が⼤変 リリースプロセスが複雑 • リリース作業(⼿続き含む)に5⽇かかる • 詳しくは後半に。。。 8 私たちの課題
  6. ©2022 Mirai Translate, Inc. 競合開発が多い • Mirai Translatorは複数チームで開発している • チーム間での競合開発が多発している

    • リリースタイミングの調整が⼤変 リリースプロセスが複雑 • リリース作業(⼿続き含む)に5⽇かかる • 詳しくは後半に。。。 9 私たちの課題 まずはこちらの話をします
  7. ©2022 Mirai Translate, Inc. 各機能が密結合 • 同じDBの同じテーブルを参照 • 同期的に呼び出している箇所も存在 デプロイ単位がシステム全体

    • “A機能だけリリース”ができない • 複数案件をまとめてリリースしがち • リードタイムが⼀番遅い案件に 引っ張られる 12 技術負債を抱えたモノリス DB Mirai Translator A機能 チームA B機能 チームB C機能 チームC
  8. ©2022 Mirai Translate, Inc. 14 マイクロサービス DB Aサービス A機能 チームA

    DB Bサービス B機能 チームB DB Cサービス C機能 チームC 利点 • サービス単位にデプロイできる • サービス間の依存が発⽣しにくい ⽋点 • サービス間のトランザクションを 保てない • 全体のデプロイや運⽤は複雑化 • モノリスでは不要な技術が必要 複数のサービスでシステムを構成する
  9. ©2022 Mirai Translate, Inc. 理由①︓サービス単位のデプロイを可能にしたい • サービス間で競合開発が発⽣しない状態を⽬指す 理由②︓モノリスのリファクタリングによる解決は困難 • 不適切なデータモデリングに起因する複雑さが存在

    • テーブル定義の改修は難易度が⾼い 理由③︓トランザクションの必要箇所は少ない(ハズ) • 現状の仕様を鑑みるに、結果整合性でもよい箇所が多い (もちろん今後ビジネスサイドとの合意は必要) 15 マイクロサービスを⽬指す理由
  10. ©2022 Mirai Translate, Inc. 年単位の時間をかけて構築し、完成したら置き換える 不採⽤ • リスクが⾼い • 新規機能開発は⽌められないため、リソース不⾜

    17 ビッグバンリライト DB Mirai Translator A機能 B機能 C機能 DB Aサービス A機能 DB Bサービス B機能 DB Cサービス C機能
  11. ©2022 Mirai Translate, Inc. 18 ストラングラーパターン(*) DB Mirai Translator A機能

    B機能 C機能 DB Aサービス A機能 DB Mirai Translator B機能 C機能 (* “Martin Fowlerʼs Bliki (ja)” https://bliki-ja.github.io/StranglerApplication/) ⼀部分だけ置き換える〜を繰り返す 採⽤ • ⼩さい単位で置き換えられるためリスクが低い • 新規機能開発も⽌めなくてよい
  12. ©2022 Mirai Translate, Inc. • サービス間の⾮同期なメッセージ ング基盤 • モノリスからサービスへのデータ 同期基盤

    • ユーザーリクエストをサービスと モノリスに振り分ける基盤 ...etc 19 移⾏に向けた課題 DB Aサービス A機能 DB Mirai Translator B機能 C機能 Proxy モノリスでは不要だった技術基盤が必要
  13. ©2022 Mirai Translate, Inc. • OSSの分散メッセージングプラットフォーム 23 Apache Kafka •

    “at least once” かつ メッセージ順序保証可 • メッセージのスキーマは任意 • 複数Publisher(Producer)による利⽤可能 • 複数Subscriber(Consumer)による利⽤可能 • メッセージを内部で永続化可能 ®
  14. ©2022 Mirai Translate, Inc. • OSSのCDCプラットフォーム • Kafka Connectフレームワークを⽤いて構築されている •

    RDBのログ(*)を監視し、Kafkaメッセージに変換する 24 Debezium CDC(Change Data Capture) • DBの変更を追跡するシステムのこと • 既存システムの改修なしに別システムからデータ変更を検知可能 (* RDB以外にも対応)
  15. ©2022 Mirai Translate, Inc. 25 どうやって構築しているか • MSK(Amazon Managed Streaming

    for Apache Kafka) • MSK Connect • Lambda MSKトリガー Kafka のマネージドサービス Kafka Connectフレームワークのマネージドサービス Lambdaの呼び出しトリガーの1つにMSKあり AWSのサービスを利⽤
  16. ©2022 Mirai Translate, Inc. 分かったこと • メッセージの重複⽋損なしに通信できている • KafkaとDebeziumのパフォーマンスは⼗分 →RDBの変更を100ms未満でメッセージ化

    今後の課題 • むしろアプリケーション側がKafkaに追いついていない →Lambdaの並列度向上やアプリの並列化が必要 • 監視対象メトリクスが未精査 →CloudWatchでの取得可不可、ほか監視ツールやサービスの選定 27 今のところの成果 最⼩構成のデータ同期基盤を組み、負荷試験や復旧試験を実施
  17. ©2022 Mirai Translate, Inc. 28 ここまでのまとめ リーン開発に向けた私たちの課題 • 競合開発が多い •

    リリースプロセスが複雑 マイクロサービスを⽬指している話 • 競合開発を減らすために、ストラングラーパターンによるマイ クロサービス移⾏を⽬指している • KafkaやDebeziumを⽤いて、マイクロサービスに向けた基盤 を構築している
  18. ©2022 Mirai Translate, Inc. ⾃⼰紹介 30 30 名前 川村 亮清(Ryosei

    Kawamura) ニックネーム jeff 所属 株式会社みらい翻訳 役割 SRE 趣味 キャンプ / ピアノ @kobarasukimaro
  19. ©2022 Mirai Translate, Inc. リリースの現状 その後・・・ • サービスが成⻑してセールスからの要望やユーザーフィードバッ クが増えた →

    それを元に開発&リリースを⾏いたい • Dev と Ops が分かれていると改善スピードについていけない → 現在は開発チームがリリースまで⾏っている • リーン開発の第1歩は踏み出し始めている 33
  20. ©2022 Mirai Translate, Inc. リリースの現状 • リリースのやり⽅はあまり変わっていない → ⼿続きや⼿順が多い・・・ •

    そのため開発チームのリリース負担が⼤きい • QA 完了からリリースまでリードタイム5⽇ほどかかっている 34 リリース準備 リリース承認 Stgリリース 商⽤リリース QA完了〜リリース 約5⽇
  21. ©2022 Mirai Translate, Inc. SRE がやりたいこと • SRE はリリースのリードタイムを短縮したい •

    ⽬的は開発者の負担を減らしてよりリーン開発をできるようにす ること 36 リリースサイクルがボト ルネックでこのサイクル を回すのが遅い
  22. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • Mirai Translator

    の構成について • Mirai Translator はプラン(ベーシック、エンタープライズな ど)が複数存在し、それぞれのプラン毎に VPC レベルでリソー スが分かれている 42 AWS Plan-a Plan-b Plan-c
  23. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • Mirai Translator

    はステージング環境、商⽤環境があり、それぞ れにプランのリソースが存在する 43 AWS(prd) AWS(stg) Plan-a Plan-b Plan-c Plan-a Plan-b Plan-c
  24. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • Mirai Translator

    はプラン&環境ごとにリリースブランチが存在 し、ブランチごとにビルドとデプロイ を⾏っている 44 feature release/stg-plan-a release/stg-plan-b release/stg-plan-c GitHub AWS(stg) build&deploy Plan-a Plan-b Plan-c AWS(prd) Plan-a Plan-b Plan-c release/prd-plan-a release/prd-plan-b release/prd-plan-c build&deploy build&deploy build&deploy build&deploy build&deploy
  25. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し プラン・環境毎にブランチが分かれていることの課題 • コードベースが環境ごとに異なる

    → ブランチ毎のコミットを気にしなくてはならない • リリースブランチ毎にビルドを⾏っている → 時間がかかるし安全ではない • リリースブランチ毎にPRを作っている → PRを作る⼿間もかかるしレビューする⼿間もかかる 45
  26. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • 単⼀のリリースブランチからデプロイできるようにブランチ戦略 を変更

    • リリースブランチでビルドした成果物もプラン・環境毎に単⼀に した • デプロイは全てのプラン及び環境で同⼀の成果物を使⽤する 47
  27. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • ChatOps を開発することで単⼀のブランチから複数の環境へのデ

    プロイを柔軟に⾏えるように対応 49 feature release GitHub AWS Plan-a Plan-b Plan-c build deploy deploy deploy slack Slash command developer
  28. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • 最終的にブランチとデプロイ対象の関係はここから 51

    feature release/stg-plan-a release/stg-plan-b release/stg-plan-c GitHub AWS(stg) build&deploy Plan-a Plan-b Plan-c AWS(prd) Plan-a Plan-b Plan-c release/prd-plan-a release/prd-plan-b release/prd-plan-c build&deploy build&deploy build&deploy build&deploy build&deploy
  29. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • こうなりました 52

    developer feature release GitHub AWS Plan-a Plan-b Plan-c build deploy deploy deploy slack Slash command
  30. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • CI/CD

    ツールを CircleCI → GitHub Actions に置き換え • CI/CD の実装をより柔軟に⾏いたいため • GitHub Actions の利点 → GitHub 上でデプロイまで完結できること → コードのメンテナンス性 → OIDC サポート • CircleCI と GitHub Actions のワークフロー定義はどちらも yaml なので移⾏の難易度は⾼くなかった 55
  31. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • GitHub

    Actions のコードのメンテナンス性について • Reusable workflows 機能が強⼒ 56 repo workflow1 workflow2 workflow3 reusable workflow 共通処理を1つにま とめて他のワークフ ローから参照できる
  32. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • internal

    repo だとオーガニゼーション内の共通ワークフローとし て定義できる 57 repo1 workflow reusable workflow repo2 workflow repo3 workflow reusable workflow repo
  33. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • Reusable

    workflows で何が嬉しいか︖ • 複数ワークフローで共通処理がある場合、Reusable workflows だけ変更すれば良いので変更負荷が低い → Mirai Translator は同じ⽅法でビルドしているリポジトリ が複数ある • 今後マイクロサービス化でアプリケーションが増えていくことが 予想されるのでこの利点は⼤きい 58
  34. ©2022 Mirai Translate, Inc. 取り組んだことまとめ • SRE でデプロイの改善を⾏った • ブランチ戦略の⾒直し、それによるデプロイ⽅法の改善

    • デプロイ⽅法を改善する中で CI/CD ツールの置き換えなどでデ プロイをより効率化する改善を⾏った 60
  35. ©2022 Mirai Translate, Inc. どう改善されたか 63 • リリースのリードタイム短縮 → 5⽇

    から 2⽇に短縮 → リリースの⼿続きや⼿順の⾒直しでリードタイムはさらに 短縮できる⾒込み • デプロイ安全性向上 → 単⼀の成果物を使⽤するようになったので環境毎のビルド や環境差分を気にする必要がなくなった
  36. ©2022 Mirai Translate, Inc. 今後やりたいこと • デプロイとリリースの分離 → デプロイ︓アプリケーションを新しく配置すること →

    リリース︓エンドユーザーがデプロイしたアプリケーション を使える状態にすること • アプリケーションのインフラをコンテナ化 → よりデプロイしやすい構成にしてリリースサイクルを⾼速に する 65