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

by mirai_miyata

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

©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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Slide 51

Slide 51 text

©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

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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