MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy

Transcript

1. レガシーに立ち向かう アーキテクチャ選定への道のり

2. モジュール や パッケージの構成 チーム開発 や アーキテクチャの話

3. Go Conference 2019 Spring メディアドゥによるスポンサーセッションで話した内容。 • システム統合を進めている • 既存のシステムはモノリシックで変更に強くない •

   将来的にはオンプレからクラウドに移す • どのように大胆なシステム対応を乗り切るのか

4. Go Conference 2019 Spring

5. 方針 A : 今のシステムをそのまま改修する B : 新しいシステムを作る

6. 方針 A : 今のシステムをそのまま改修する B : 新しいシステムを作る C : 漸進的に変えていく

7. 概念的 イメージ : フェーズ 1 既存システム モノリシック 新規システム マイクロ オンプレ

   クラウド AWS Java PHP Go PostgreSQL Storage DynamoDB S3 機能切り出し (開発) 互換データ提供 (運用)

8. 概念的 イメージ : フェーズ 2 既存システム モノリシック 新規システム マイクロ クラウド

   AWS Java PHP Go PostgreSQL Storage DynamoDB S3

9. 概念的 イメージ : フェーズ 3 新規システム マイクロ クラウド AWS Go

   DynamoDB, RDS S3, EFS

10. Go の強みを活かし続ける仕組みづくり

11. 作戦 チームは全員新しくシステムを立ち上げるのは初めてであり、戦略が必要。 • 開発・運用の物理的・心理的なハードルを下げる • スケールを続けられる仕組みを作る • リトライできる仕組みを作る

12. 手法 • Go • マイクロサービスアーキテクチャ • モノレポ • クリーンアーキテクチャ

13. 関心事の分離 と 効率化 は 相反する要素

14. Go 大規模開発から、スモールスタートにも適した言語である。 • 学習コストが低い • シングルバイナリにまとまるため、コンテナベースの運用と相性が良い • エラーハンドリングや、テスト等、コミュニティ全体で文化の共有が活発 • Go

    Modules、Go Proxy 等、エコシステムは利便性が高く、堅牢である

15. マイクロサービスアーキテクチャ 定められたサービス境界の中に、開発の影響を抑え込む。 • データベーススコープはまとめる、実質はサービスベースアーキテクチャ • 最初からマイクロサービスにするというのは、アンチパターンだが・・・ ◦ 今回について言えば、散々運用したレガシーシステムが対象 ◦ 辛い部分が分かっているため、その背景を元にサービス分割が可能

    • 外部ライブラリへの依存、コード変更の影響をシステム全体に波及させない

16. モノレポ サービス横断的な機能の提供を効率化し、設計文化を共有する。 • チームの人数は多くない ◦ 全員が新卒入社の社員 ◦ 8年目 1人(濱口)、4年目 1人、3年目

    1人、2年目 2人 • リポジトリの数は、その数に比例して管理や把握が重荷となる ◦ コードもサービスの数も把握が難しくなりがち • サービス全体で共通する機能の開発を効率化する

17. モノレポの課題 更新対象のサービスのみをビルド・デプロイ仕組みが必要。 • CI/CD の処理時間が積み上がり、開発速度に悪影響を与える • 本番デプロイで無関係なサービスに対する、不要なデプロイが発生する

18. モノレポの課題の解決 CircleCI 等で細かな設定などが可能だが、今回はAWSで完結させている。 • CodeBuild はプッシュやプルリクエストの発行など、 Gitリポジトリのアクションに基づくトリガーを絞ることができる • 各種サービス用のディレクトリ配下に変更がある場合のみ、 対象のサービスのCI/CDを実行する

19. クリーンアーキテクチャ 実行方法、実行環境に依存しない、変更に強い設計にする。 • ビジネスロジックと、ソフトウェアを取り巻く環境を分離する ◦ 再利用可能、取り替え可能なパーツでアプリケーションを作る ◦ コンテナベース、サーバレス、どちらも対応可能な形にする ◦ ビジネス要件の変更に合わせた柔軟な対応を可能にする

20. クリーンアーキテクチャの課題 • チームで把握度が異なる場合の、コーチングと知識共有が難しい ◦ 実装に悩んで進みづらくなる ▪ パッケージの名前、細かい末端のパッケージの分け方に悩む ▪ インターフェイス、構造体の名前に悩む ◦

    インターフェースが乱立させ、それをテストするためのモックも大量に発生する • 似た名称のファイル、パッケージ、インターフェイス、構造体が乱立し、 組みづらさを感じる

21. クリーンアーキテクチャの課題の解決 • マイクロサービスアーキテクチャで、 細かくサービス・モジュールを分けているため、 各モジュールプログラムの分量は小さくなる • リポジトリ全体を一つのクリーンアーキテクチャの分け方で書かず、 各サービスの中でクリーンアーキテクチャを実践する • そもそもクリーンアーキテクチャである必要すらない粒度であれば、

    ある程度は立ち上げの速度を重視した、ストレートな設計を採用すれば良い

22. pkg go.mod /log, /error … etc ロギングやエラーハンドリングなど、 横断的に利用可能であり、 文化に関わる機能を提供。 service

    go.mod サービス単位 パッケージ モジュール単位 パッケージ 〜.go 〜.go サービス境界毎にパッケージを作成し、 モジュール単位でプログラムが並ぶ。 サービス単位にCI/CDを実行する。 リポジトリ ルートの構成

23. test unit-test.yml unit-test.Dockerfile サービスを横断して、 全体の機能が正しく動作するか テストする機能を提供する。 build サービス全体を構築するための ビルドスクリプトなどを提供する。 プルリクエストの作成、マージのタイミングで、

    対象ブランチ用の実行環境を自動構築させる等。 リポジトリ ルートの構成 その他必要なテスト machine-destroyer.yml machine-builder.yml

24. レコメンドサービス(機械学習) recommend/ 学習モジュール learning/ クリーンアーキテクチャに沿ったパッケージ構成/ 　　〜.go go.mod Dockerfile Makefile リポジトリ

    service配下の構成 (例) 結果出力モジュール result/ モジュール単位の ビルドやテストは、 モジュールの中身で 完結させる。 学習モジュールと同様

25. ハードル を 下げる スケール を 続けられる リトライ できる

26. アーキテクチャを ツールとして利用し システム開発を総合的に支援する

27. まとめ : ハードルを下げる • Go ◦ 始めやすさ、習得しやすさ • マイクロサービスアーキテクチャ ◦

    変更の影響を狭め、チームの開発・運用に対するハードルを下げる ▪ 設計者のハードルは上がる、チームの知識拡充はミッションとなる • モノレポ ◦ 隣のサービスのコードが既に手元にあり、見通しが良い、参考にしやすい ◦ プロジェクト横断的な機能の提供が容易 • クリーンアーキテクチャ ◦ マイクロサービス、モノレポとの相乗効果、隣のサービスの全体設計を参考可能

28. まとめ : スケールを続けられる • Go ◦ シングルバイナリという取り回しの良さが、マイクロサービスとの相性が良い • マイクロサービスアーキテクチャ ◦

    必要な箇所だけの、ビルドとデプロイ • モノレポ ◦ サービスが増えても、リポジトリ配下のディレクトリとファイルが増えるのみ • クリーンアーキテクチャ ◦ ビジネス要件等の変更による、柔軟な対応

29. まとめ : リトライできる • Go ◦ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い • マイクロサービスアーキテクチャ ◦

    サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易

30. 終了