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

デブサミ2022登壇資料 https://event.shoeisha.jp/devsumi/20220217/session/3707/

Transcript

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

   View Slide

2. ©2022 Mirai Translate, Inc.
   ⾃⼰紹介
   2
   2
   名前
   宮⽥ 周（Shu Miyata）
   ニックネーム
   ein
   所属
   株式会社みらい翻訳
   役割
   アプリケーションエンジニア
   趣味
   ゲーム / 料理
   @miyagon000v
   

   View Slide

3. ©2022 Mirai Translate, Inc.
   3
   株式会社みらい翻訳
   企業向けクラウドAI⾃動翻訳
   Mirai Translator
   • ⾼い翻訳精度（TOEIC 960点〜）
   • ⾼いセキュリティ（ISO27001/ISO27017）
   • ユーザー視点でのUX
   ®
   VISION
   ⾔語の壁を超え、新しい⽣活と仕事の様式をもたらす共通語の機能
   を機械翻訳として2028年までに作る。
   （世界のすべての⼈々に英語を⺟語とする⼈々と同じ体験を与える）
   

   View Slide

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

   View Slide

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

   View Slide

6. ©2022 Mirai Translate, Inc.
   リーン開発とは︖
   • 開発プロセスからムダをなくし、
   ⾼速に開発すること
   なぜリーン開発をしたい︖
   • リーンスタートアップに基づき、
   ⾼速に仮説検証したい
   6
   リーン開発
   アイデア
   サービス
   構築する
   データ
   計測する
   学ぶ
   

   View Slide

7. ©2022 Mirai Translate, Inc.
   私たちの現状と理想
   7
   現状 理想
   デプロイ頻度
   １回／週
   開発リードタイム（設計〜リリース）
   １週間〜1ヶ⽉以上
   デプロイ頻度
   １回／⽇
   開発リードタイム（設計〜リリース）
   １⽇〜１週間
   ＝理想よりも開発スピードが遅い︕
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. ©2022 Mirai Translate, Inc.
    各機能が密結合
    • 同じDBの同じテーブルを参照
    • 同期的に呼び出している箇所も存在
    デプロイ単位がシステム全体
    • “A機能だけリリース”ができない
    • 複数案件をまとめてリリースしがち
    • リードタイムが⼀番遅い案件に
    引っ張られる
    12
    技術負債を抱えたモノリス
    DB
    Mirai Translator
    A機能
    チームA
    B機能
    チームB
    C機能
    チームC
    

    View Slide

13. ©2022 Mirai Translate, Inc.
    • 各機能が疎結合
    • あるチームのリリース（デプロイ）を独⽴して実施できる
    →その為にマイクロサービスを⽬指す
    13
    理想的な状態
    

    View Slide

14. ©2022 Mirai Translate, Inc.
    14
    マイクロサービス
    DB
    Aサービス
    A機能
    チームA
    DB
    Bサービス
    B機能
    チームB
    DB
    Cサービス
    C機能
    チームC
    利点
    • サービス単位にデプロイできる
    • サービス間の依存が発⽣しにくい
    ⽋点
    • サービス間のトランザクションを
    保てない
    • 全体のデプロイや運⽤は複雑化
    • モノリスでは不要な技術が必要
    複数のサービスでシステムを構成する
    

    View Slide

15. ©2022 Mirai Translate, Inc.
    理由①︓サービス単位のデプロイを可能にしたい
    • サービス間で競合開発が発⽣しない状態を⽬指す
    理由②︓モノリスのリファクタリングによる解決は困難
    • 不適切なデータモデリングに起因する複雑さが存在
    • テーブル定義の改修は難易度が⾼い
    理由③︓トランザクションの必要箇所は少ない（ハズ）
    • 現状の仕様を鑑みるに、結果整合性でもよい箇所が多い
    （もちろん今後ビジネスサイドとの合意は必要）
    15
    マイクロサービスを⽬指す理由
    

    View Slide

16. ©2022 Mirai Translate, Inc.
    16
    どのようにマイクロサービスに移⾏するか︖
    

    View Slide

17. ©2022 Mirai Translate, Inc.
    年単位の時間をかけて構築し、完成したら置き換える
    不採⽤
    • リスクが⾼い
    • 新規機能開発は⽌められないため、リソース不⾜
    17
    ビッグバンリライト
    DB
    Mirai Translator
    A機能 B機能 C機能
    DB
    Aサービス
    A機能
    DB
    Bサービス
    B機能
    DB
    Cサービス
    C機能
    

    View Slide

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/)
    ⼀部分だけ置き換える〜を繰り返す
    採⽤
    • ⼩さい単位で置き換えられるためリスクが低い
    • 新規機能開発も⽌めなくてよい
    

    View Slide

19. ©2022 Mirai Translate, Inc.
    • サービス間の⾮同期なメッセージ
    ング基盤
    • モノリスからサービスへのデータ
    同期基盤
    • ユーザーリクエストをサービスと
    モノリスに振り分ける基盤
    ...etc
    19
    移⾏に向けた課題
    DB
    Aサービス
    A機能
    DB
    Mirai Translator
    B機能 C機能
    Proxy
    モノリスでは不要だった技術基盤が必要
    

    View Slide

20. ©2022 Mirai Translate, Inc.
    20
    今取り組んでいること
    

    View Slide

21. ©2022 Mirai Translate, Inc.
    ⼤まかなロードマップ
    1. 技術基盤を構築する ←ｲﾏｺｺ!
    2. マイクロサービスの試験実装
    3. 主要機能のマイクロサービス化開始
    21
    今取り組んでいること
    

    View Slide

22. ©2022 Mirai Translate, Inc.
    • Kafkaを⽤いた⾮同期メッセージング基盤
    • Debeziumを⽤いたデータ同期基盤
    22
    今作っている技術基盤
    DB
    Aサービス
    A機能
    DB
    Mirai Translator
    B機能 C機能
    データ
    同期
    

    View Slide

23. ©2022 Mirai Translate, Inc.
    • OSSの分散メッセージングプラットフォーム
    23
    Apache Kafka
    • “at least once” かつ メッセージ順序保証可
    • メッセージのスキーマは任意
    • 複数Publisher(Producer)による利⽤可能
    • 複数Subscriber(Consumer)による利⽤可能
    • メッセージを内部で永続化可能
    ®
    

    View Slide

24. ©2022 Mirai Translate, Inc.
    • OSSのCDCプラットフォーム
    • Kafka Connectフレームワークを⽤いて構築されている
    • RDBのログ(*)を監視し、Kafkaメッセージに変換する
    24
    Debezium
    CDC(Change Data Capture)
    • DBの変更を追跡するシステムのこと
    • 既存システムの改修なしに別システムからデータ変更を検知可能
    (* RDB以外にも対応）
    

    View Slide

25. ©2022 Mirai Translate, Inc.
    25
    どうやって構築しているか
    • MSK(Amazon Managed Streaming for Apache Kafka)
    • MSK Connect
    • Lambda MSKトリガー
    Kafka のマネージドサービス
    Kafka Connectフレームワークのマネージドサービス
    Lambdaの呼び出しトリガーの１つにMSKあり
    AWSのサービスを利⽤
    

    View Slide

26. ©2022 Mirai Translate, Inc.
    • Kafkaを⽤いた⾮同期メッセージング基盤
    • Debeziumを⽤いたデータ同期基盤
    26
    今作っている技術基盤
    DB
    Aサービス
    A機能
    DB
    Mirai Translator
    B機能 C機能
    MSK
    (Kafka)
    MSK Connect
    (Debezium)
    

    View Slide

27. ©2022 Mirai Translate, Inc.
    分かったこと
    • メッセージの重複⽋損なしに通信できている
    • KafkaとDebeziumのパフォーマンスは⼗分
    →RDBの変更を100ms未満でメッセージ化
    今後の課題
    • むしろアプリケーション側がKafkaに追いついていない
    →Lambdaの並列度向上やアプリの並列化が必要
    • 監視対象メトリクスが未精査
    →CloudWatchでの取得可不可、ほか監視ツールやサービスの選定
    27
    今のところの成果
    最⼩構成のデータ同期基盤を組み、負荷試験や復旧試験を実施
    

    View Slide

28. ©2022 Mirai Translate, Inc.
    28
    ここまでのまとめ
    リーン開発に向けた私たちの課題
    • 競合開発が多い
    • リリースプロセスが複雑
    マイクロサービスを⽬指している話
    • 競合開発を減らすために、ストラングラーパターンによるマイ
    クロサービス移⾏を⽬指している
    • KafkaやDebeziumを⽤いて、マイクロサービスに向けた基盤
    を構築している
    

    View Slide

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

    View Slide

30. ©2022 Mirai Translate, Inc.
    ⾃⼰紹介
    30
    30
    名前
    川村 亮清（Ryosei Kawamura）
    ニックネーム
    jeff
    所属
    株式会社みらい翻訳
    役割
    SRE
    趣味
    キャンプ / ピアノ
    @kobarasukimaro
    

    View Slide

31. ©2022 Mirai Translate, Inc.
    リリースの現状
    31
    

    View Slide

32. ©2022 Mirai Translate, Inc.
    リリースの現状
    今よりもう少し前の話・・・
    • 以前は開発チームが開発・改修した機能をインフラチームにリ
    リースを依頼していた
    → 通信キャリア並みの品質を求める⽂化
    32
    

    View Slide

33. ©2022 Mirai Translate, Inc.
    リリースの現状
    その後・・・
    • サービスが成⻑してセールスからの要望やユーザーフィードバッ
    クが増えた
    → それを元に開発＆リリースを⾏いたい
    • Dev と Ops が分かれていると改善スピードについていけない
    → 現在は開発チームがリリースまで⾏っている
    • リーン開発の第1歩は踏み出し始めている
    33
    

    View Slide

34. ©2022 Mirai Translate, Inc.
    リリースの現状
    • リリースのやり⽅はあまり変わっていない
    → ⼿続きや⼿順が多い・・・
    • そのため開発チームのリリース負担が⼤きい
    • QA 完了からリリースまでリードタイム5⽇ほどかかっている
    34
    リリース準備 リリース承認
    Stgリリース 商⽤リリース
    QA完了〜リリース
    約5⽇
    

    View Slide

35. ©2022 Mirai Translate, Inc.
    SRE がやりたいこと
    35
    

    View Slide

36. ©2022 Mirai Translate, Inc.
    SRE がやりたいこと
    • SRE はリリースのリードタイムを短縮したい
    • ⽬的は開発者の負担を減らしてよりリーン開発をできるようにす
    ること
    36
    リリースサイクルがボト
    ルネックでこのサイクル
    を回すのが遅い
    

    View Slide

37. ©2022 Mirai Translate, Inc.
    取り組んだこと
    37
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. ©2022 Mirai Translate, Inc.
    取り組んだこと – ブランチ戦略⾒直し
    • アプリケーションのソースコードは GitHub で管理している
    • ブランチ戦略は git-flow ベース
    41
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

46. ©2022 Mirai Translate, Inc.
    取り組んだこと – ブランチ戦略⾒直し
    プラン・環境毎にブランチが分かれていることの課題
    • プランが増えるとその分デプロイの負担も増えていく・・・
    46
    

    View Slide

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

    View Slide

48. ©2022 Mirai Translate, Inc.
    取り組んだこと – ブランチ戦略⾒直し
    48
    feature
    release
    GitHub AWS
    Plan-a
    Plan-b
    Plan-c
    build
    deploy
    deploy
    deploy
    

    View Slide

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
    

    View Slide

50. ©2022 Mirai Translate, Inc.
    取り組んだこと – ブランチ戦略⾒直し
    • ChatOps を開発することで単⼀のブランチから複数の環境へのデ
    プロイを柔軟に⾏えるように対応
    50
    

    View Slide

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
    

    View Slide

52. ©2022 Mirai Translate, Inc.
    取り組んだこと – ブランチ戦略⾒直し
    • こうなりました
    52
    developer
    feature
    release
    GitHub AWS
    Plan-a
    Plan-b
    Plan-c
    build
    deploy
    deploy
    deploy
    slack
    Slash command
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

59. ©2022 Mirai Translate, Inc.
    取り組んだことまとめ
    59
    

    View Slide

60. ©2022 Mirai Translate, Inc.
    取り組んだことまとめ
    • SRE でデプロイの改善を⾏った
    • ブランチ戦略の⾒直し、それによるデプロイ⽅法の改善
    • デプロイ⽅法を改善する中で CI/CD ツールの置き換えなどでデ
    プロイをより効率化する改善を⾏った
    60
    

    View Slide

61. ©2022 Mirai Translate, Inc.
    どう改善されたか
    61
    

    View Slide

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

    View Slide

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

    View Slide

64. ©2022 Mirai Translate, Inc.
    今後やりたいこと
    64
    

    View Slide

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

    View Slide

66. ©2022 Mirai Translate, Inc.
    全体のまとめ
    66
    

    View Slide

67. ©2022 Mirai Translate, Inc.
    全体のまとめ
    リーンな開発を⽬指すために・・・
    • マイクロサービスを⽬指している。そのための技術基盤の構築を進
    めている
    • デプロイ改善の取り組みでリリースリードタイムを 5⽇ → 2⽇に短
    縮
    67
    

    View Slide

68. ©2022 Mirai Translate, Inc.
    あなたのスキルをみらい翻訳で活か
    しませんか︖
    リーンな開発を⽬指したい⽅からの
    ご応募をお待ちしております。
    気になる⽅は Wantedly や コーポ
    レートサイトからご連絡ください。
    68
    

    View Slide

69. ©2022 Mirai Translate, Inc.
    ご清聴ありがとうございました
    69
    

    View Slide