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.
    リーンな開発を⽬指す第⼀歩
    〜マイクロサービス化と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回/週
    開発リードタイム(設計〜リリース)
    1週間〜1ヶ⽉以上
    デプロイ頻度
    1回/⽇
    開発リードタイム(設計〜リリース)
    1⽇〜1週間
    =理想よりも開発スピードが遅い︕

    View Slide

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

    View Slide

  9. ©2022 Mirai Translate, Inc.
    競合開発が多い
    • Mirai Translatorは複数チームで開発している
    • チーム間での競合開発が多発している
    • リリースタイミングの調整が⼤変
    リリースプロセスが複雑
    • リリース作業(⼿続き含む)に5⽇かかる
    • 詳しくは後半に。。。
    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の呼び出しトリガーの1つに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