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

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

8e9ea72074a5a8221f7979d522048496?s=47 mirai_miyata
February 22, 2022

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

8e9ea72074a5a8221f7979d522048496?s=128

mirai_miyata

February 22, 2022
Tweet

Other Decks in Technology

Transcript

  1. ©2022 Mirai Translate, Inc. リーンな開発を⽬指す第⼀歩 〜マイクロサービス化とGitHub Actionsを活⽤したリリース改善〜 株式会社みらい翻訳 宮⽥ 周

    川村 亮清 2022.2.18
  2. ©2022 Mirai Translate, Inc. ⾃⼰紹介 2 2 名前 宮⽥ 周(Shu

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

    ⾼い翻訳精度(TOEIC 960点〜) • ⾼いセキュリティ(ISO27001/ISO27017) • ユーザー視点でのUX ® VISION ⾔語の壁を超え、新しい⽣活と仕事の様式をもたらす共通語の機能 を機械翻訳として2028年までに作る。 (世界のすべての⼈々に英語を⺟語とする⼈々と同じ体験を与える)
  4. ©2022 Mirai Translate, Inc. 1. リーン開発に向けた私たちの課題 2. マイクロサービスを⽬指している話 3. リリースプロセス改善に取り組んだ話

    4 今⽇お話しすること
  5. ©2022 Mirai Translate, Inc. 1.リーン開発に向けた私たちの課題 2. マイクロサービスを⽬指している話 3. リリースプロセス改善に取り組んだ話 5

  6. ©2022 Mirai Translate, Inc. リーン開発とは︖ • 開発プロセスからムダをなくし、 ⾼速に開発すること なぜリーン開発をしたい︖ •

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

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

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

    • リリースタイミングの調整が⼤変 リリースプロセスが複雑 • リリース作業(⼿続き含む)に5⽇かかる • 詳しくは後半に。。。 9 私たちの課題 まずはこちらの話をします
  10. ©2022 Mirai Translate, Inc. 1. リーン開発に向けた私たちの課題 2.マイクロサービスを⽬指している話 3. リリースプロセス改善に取り組んだ話 10

  11. ©2022 Mirai Translate, Inc. 11 なぜ競合開発が多いのか︖

  12. ©2022 Mirai Translate, Inc. 各機能が密結合 • 同じDBの同じテーブルを参照 • 同期的に呼び出している箇所も存在 デプロイ単位がシステム全体

    • “A機能だけリリース”ができない • 複数案件をまとめてリリースしがち • リードタイムが⼀番遅い案件に 引っ張られる 12 技術負債を抱えたモノリス DB Mirai Translator A機能 チームA B機能 チームB C機能 チームC
  13. ©2022 Mirai Translate, Inc. • 各機能が疎結合 • あるチームのリリース(デプロイ)を独⽴して実施できる →その為にマイクロサービスを⽬指す 13

    理想的な状態
  14. ©2022 Mirai Translate, Inc. 14 マイクロサービス DB Aサービス A機能 チームA

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

    • テーブル定義の改修は難易度が⾼い 理由③︓トランザクションの必要箇所は少ない(ハズ) • 現状の仕様を鑑みるに、結果整合性でもよい箇所が多い (もちろん今後ビジネスサイドとの合意は必要) 15 マイクロサービスを⽬指す理由
  16. ©2022 Mirai Translate, Inc. 16 どのようにマイクロサービスに移⾏するか︖

  17. ©2022 Mirai Translate, Inc. 年単位の時間をかけて構築し、完成したら置き換える 不採⽤ • リスクが⾼い • 新規機能開発は⽌められないため、リソース不⾜

    17 ビッグバンリライト DB Mirai Translator A機能 B機能 C機能 DB Aサービス A機能 DB Bサービス B機能 DB Cサービス C機能
  18. ©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/) ⼀部分だけ置き換える〜を繰り返す 採⽤ • ⼩さい単位で置き換えられるためリスクが低い • 新規機能開発も⽌めなくてよい
  19. ©2022 Mirai Translate, Inc. • サービス間の⾮同期なメッセージ ング基盤 • モノリスからサービスへのデータ 同期基盤

    • ユーザーリクエストをサービスと モノリスに振り分ける基盤 ...etc 19 移⾏に向けた課題 DB Aサービス A機能 DB Mirai Translator B機能 C機能 Proxy モノリスでは不要だった技術基盤が必要
  20. ©2022 Mirai Translate, Inc. 20 今取り組んでいること

  21. ©2022 Mirai Translate, Inc. ⼤まかなロードマップ 1. 技術基盤を構築する ←イマココ! 2. マイクロサービスの試験実装

    3. 主要機能のマイクロサービス化開始 21 今取り組んでいること
  22. ©2022 Mirai Translate, Inc. • Kafkaを⽤いた⾮同期メッセージング基盤 • Debeziumを⽤いたデータ同期基盤 22 今作っている技術基盤

    DB Aサービス A機能 DB Mirai Translator B機能 C機能 データ 同期
  23. ©2022 Mirai Translate, Inc. • OSSの分散メッセージングプラットフォーム 23 Apache Kafka •

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

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

    for Apache Kafka) • MSK Connect • Lambda MSKトリガー Kafka のマネージドサービス Kafka Connectフレームワークのマネージドサービス Lambdaの呼び出しトリガーの1つにMSKあり AWSのサービスを利⽤
  26. ©2022 Mirai Translate, Inc. • Kafkaを⽤いた⾮同期メッセージング基盤 • Debeziumを⽤いたデータ同期基盤 26 今作っている技術基盤

    DB Aサービス A機能 DB Mirai Translator B機能 C機能 MSK (Kafka) MSK Connect (Debezium)
  27. ©2022 Mirai Translate, Inc. 分かったこと • メッセージの重複⽋損なしに通信できている • KafkaとDebeziumのパフォーマンスは⼗分 →RDBの変更を100ms未満でメッセージ化

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

    リリースプロセスが複雑 マイクロサービスを⽬指している話 • 競合開発を減らすために、ストラングラーパターンによるマイ クロサービス移⾏を⽬指している • KafkaやDebeziumを⽤いて、マイクロサービスに向けた基盤 を構築している
  29. ©2022 Mirai Translate, Inc. 1. リーン開発に向けた私たちの課題 2. マイクロサービスを⽬指している話 3.リリースプロセス改善に取り組んだ話 29

  30. ©2022 Mirai Translate, Inc. ⾃⼰紹介 30 30 名前 川村 亮清(Ryosei

    Kawamura) ニックネーム jeff 所属 株式会社みらい翻訳 役割 SRE 趣味 キャンプ / ピアノ @kobarasukimaro
  31. ©2022 Mirai Translate, Inc. リリースの現状 31

  32. ©2022 Mirai Translate, Inc. リリースの現状 今よりもう少し前の話・・・ • 以前は開発チームが開発・改修した機能をインフラチームにリ リースを依頼していた →

    通信キャリア並みの品質を求める⽂化 32
  33. ©2022 Mirai Translate, Inc. リリースの現状 その後・・・ • サービスが成⻑してセールスからの要望やユーザーフィードバッ クが増えた →

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

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

  36. ©2022 Mirai Translate, Inc. SRE がやりたいこと • SRE はリリースのリードタイムを短縮したい •

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

  38. ©2022 Mirai Translate, Inc. 取り組んだこと • リリースの中で改善できることとして⼿続きや⼿順の簡略化、デ プロイ⾃体の改善など⾊々ある・・・ • 今回はデプロイ改善の話になります

    38 リリース準備 リリース承認 Stgデプロイ 商⽤デプロイ QA完了〜リリース このステップの デプロイ改善
  39. ©2022 Mirai Translate, Inc. 取り組んだこと • ブランチ戦略の⾒直し • CI/CD ツールの置き換え

    39
  40. ©2022 Mirai Translate, Inc. 取り組んだこと • ブランチ戦略の⾒直し • CI/CD ツールの置き換え

    40
  41. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • アプリケーションのソースコードは GitHub

    で管理している • ブランチ戦略は git-flow ベース 41
  42. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • Mirai Translator

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

    はステージング環境、商⽤環境があり、それぞ れにプランのリソースが存在する 43 AWS(prd) AWS(stg) Plan-a Plan-b Plan-c Plan-a Plan-b Plan-c
  44. ©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
  45. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し プラン・環境毎にブランチが分かれていることの課題 • コードベースが環境ごとに異なる

    → ブランチ毎のコミットを気にしなくてはならない • リリースブランチ毎にビルドを⾏っている → 時間がかかるし安全ではない • リリースブランチ毎にPRを作っている → PRを作る⼿間もかかるしレビューする⼿間もかかる 45
  46. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し プラン・環境毎にブランチが分かれていることの課題 • プランが増えるとその分デプロイの負担も増えていく・・・

    46
  47. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • 単⼀のリリースブランチからデプロイできるようにブランチ戦略 を変更

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

    GitHub AWS Plan-a Plan-b Plan-c build deploy deploy deploy
  49. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • ChatOps を開発することで単⼀のブランチから複数の環境へのデ

    プロイを柔軟に⾏えるように対応 49 feature release GitHub AWS Plan-a Plan-b Plan-c build deploy deploy deploy slack Slash command developer
  50. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • ChatOps を開発することで単⼀のブランチから複数の環境へのデ

    プロイを柔軟に⾏えるように対応 50
  51. ©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
  52. ©2022 Mirai Translate, Inc. 取り組んだこと – ブランチ戦略⾒直し • こうなりました 52

    developer feature release GitHub AWS Plan-a Plan-b Plan-c build deploy deploy deploy slack Slash command
  53. ©2022 Mirai Translate, Inc. 取り組んだこと • ブランチ戦略の⾒直し • CI/CD ツールの置き換え

    53
  54. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • ブランチ戦略変更

    + ChatOps 導⼊を進める中で CI/CD ツール を変更した 54
  55. ©2022 Mirai Translate, Inc. 取り組んだこと – CI/CD ツールの置き換え • CI/CD

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

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

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

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

  60. ©2022 Mirai Translate, Inc. 取り組んだことまとめ • SRE でデプロイの改善を⾏った • ブランチ戦略の⾒直し、それによるデプロイ⽅法の改善

    • デプロイ⽅法を改善する中で CI/CD ツールの置き換えなどでデ プロイをより効率化する改善を⾏った 60
  61. ©2022 Mirai Translate, Inc. どう改善されたか 61

  62. ©2022 Mirai Translate, Inc. どう改善されたか • リリースのリードタイム短縮 • デプロイ安全性向上 62

  63. ©2022 Mirai Translate, Inc. どう改善されたか 63 • リリースのリードタイム短縮 → 5⽇

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

  65. ©2022 Mirai Translate, Inc. 今後やりたいこと • デプロイとリリースの分離 → デプロイ︓アプリケーションを新しく配置すること →

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

  67. ©2022 Mirai Translate, Inc. 全体のまとめ リーンな開発を⽬指すために・・・ • マイクロサービスを⽬指している。そのための技術基盤の構築を進 めている •

    デプロイ改善の取り組みでリリースリードタイムを 5⽇ → 2⽇に短 縮 67
  68. ©2022 Mirai Translate, Inc. あなたのスキルをみらい翻訳で活か しませんか︖ リーンな開発を⽬指したい⽅からの ご応募をお待ちしております。 気になる⽅は Wantedly

    や コーポ レートサイトからご連絡ください。 68
  69. ©2022 Mirai Translate, Inc. ご清聴ありがとうございました 69