Slide 1
Slide 1 text
レガシーに立ち向かう
アーキテクチャ選定への道のり
Slide 2
Slide 2 text
モジュール や パッケージの構成
チーム開発 や アーキテクチャの話
Slide 3
Slide 3 text
Go Conference 2019 Spring
メディアドゥによるスポンサーセッションで話した内容。
● システム統合を進めている
● 既存のシステムはモノリシックで変更に強くない
● 将来的にはオンプレからクラウドに移す
● どのように大胆なシステム対応を乗り切るのか
Slide 4
Slide 4 text
Go Conference 2019 Spring
Slide 5
Slide 5 text
方針
A : 今のシステムをそのまま改修する
B : 新しいシステムを作る
Slide 6
Slide 6 text
方針
A : 今のシステムをそのまま改修する
B : 新しいシステムを作る
C : 漸進的に変えていく
Slide 7
Slide 7 text
概念的 イメージ : フェーズ 1
既存システム
モノリシック
新規システム
マイクロ
オンプレ クラウド AWS
Java
PHP
Go
PostgreSQL
Storage
DynamoDB
S3
機能切り出し
(開発)
互換データ提供
(運用)
Slide 8
Slide 8 text
概念的 イメージ : フェーズ 2
既存システム
モノリシック
新規システム
マイクロ
クラウド AWS
Java
PHP
Go
PostgreSQL
Storage
DynamoDB
S3
Slide 9
Slide 9 text
概念的 イメージ : フェーズ 3
新規システム
マイクロ
クラウド AWS
Go
DynamoDB, RDS
S3, EFS
Slide 10
Slide 10 text
Go の強みを活かし続ける仕組みづくり
Slide 11
Slide 11 text
作戦
チームは全員新しくシステムを立ち上げるのは初めてであり、戦略が必要。
● 開発・運用の物理的・心理的なハードルを下げる
● スケールを続けられる仕組みを作る
● リトライできる仕組みを作る
Slide 12
Slide 12 text
手法
● Go
● マイクロサービスアーキテクチャ
● モノレポ
● クリーンアーキテクチャ
Slide 13
Slide 13 text
関心事の分離 と 効率化 は
相反する要素
Slide 14
Slide 14 text
Go
大規模開発から、スモールスタートにも適した言語である。
● 学習コストが低い
● シングルバイナリにまとまるため、コンテナベースの運用と相性が良い
● エラーハンドリングや、テスト等、コミュニティ全体で文化の共有が活発
● Go Modules、Go Proxy 等、エコシステムは利便性が高く、堅牢である
Slide 15
Slide 15 text
マイクロサービスアーキテクチャ
定められたサービス境界の中に、開発の影響を抑え込む。
● データベーススコープはまとめる、実質はサービスベースアーキテクチャ
● 最初からマイクロサービスにするというのは、アンチパターンだが・・・
○ 今回について言えば、散々運用したレガシーシステムが対象
○ 辛い部分が分かっているため、その背景を元にサービス分割が可能
● 外部ライブラリへの依存、コード変更の影響をシステム全体に波及させない
Slide 16
Slide 16 text
モノレポ
サービス横断的な機能の提供を効率化し、設計文化を共有する。
● チームの人数は多くない
○ 全員が新卒入社の社員
○ 8年目 1人(濱口)、4年目 1人、3年目 1人、2年目 2人
● リポジトリの数は、その数に比例して管理や把握が重荷となる
○ コードもサービスの数も把握が難しくなりがち
● サービス全体で共通する機能の開発を効率化する
Slide 17
Slide 17 text
モノレポの課題
更新対象のサービスのみをビルド・デプロイ仕組みが必要。
● CI/CD の処理時間が積み上がり、開発速度に悪影響を与える
● 本番デプロイで無関係なサービスに対する、不要なデプロイが発生する
Slide 18
Slide 18 text
モノレポの課題の解決
CircleCI 等で細かな設定などが可能だが、今回はAWSで完結させている。
● CodeBuild はプッシュやプルリクエストの発行など、
Gitリポジトリのアクションに基づくトリガーを絞ることができる
● 各種サービス用のディレクトリ配下に変更がある場合のみ、
対象のサービスのCI/CDを実行する
Slide 19
Slide 19 text
クリーンアーキテクチャ
実行方法、実行環境に依存しない、変更に強い設計にする。
● ビジネスロジックと、ソフトウェアを取り巻く環境を分離する
○ 再利用可能、取り替え可能なパーツでアプリケーションを作る
○ コンテナベース、サーバレス、どちらも対応可能な形にする
○ ビジネス要件の変更に合わせた柔軟な対応を可能にする
Slide 20
Slide 20 text
クリーンアーキテクチャの課題
● チームで把握度が異なる場合の、コーチングと知識共有が難しい
○ 実装に悩んで進みづらくなる
■ パッケージの名前、細かい末端のパッケージの分け方に悩む
■ インターフェイス、構造体の名前に悩む
○ インターフェースが乱立させ、それをテストするためのモックも大量に発生する
● 似た名称のファイル、パッケージ、インターフェイス、構造体が乱立し、
組みづらさを感じる
Slide 21
Slide 21 text
クリーンアーキテクチャの課題の解決
● マイクロサービスアーキテクチャで、
細かくサービス・モジュールを分けているため、
各モジュールプログラムの分量は小さくなる
● リポジトリ全体を一つのクリーンアーキテクチャの分け方で書かず、
各サービスの中でクリーンアーキテクチャを実践する
● そもそもクリーンアーキテクチャである必要すらない粒度であれば、
ある程度は立ち上げの速度を重視した、ストレートな設計を採用すれば良い
Slide 22
Slide 22 text
pkg
go.mod
/log, /error … etc
ロギングやエラーハンドリングなど、
横断的に利用可能であり、
文化に関わる機能を提供。
service
go.mod
サービス単位
パッケージ
モジュール単位
パッケージ
〜.go
〜.go
サービス境界毎にパッケージを作成し、
モジュール単位でプログラムが並ぶ。
サービス単位にCI/CDを実行する。
リポジトリ ルートの構成
Slide 23
Slide 23 text
test
unit-test.yml
unit-test.Dockerfile
サービスを横断して、
全体の機能が正しく動作するか
テストする機能を提供する。
build
サービス全体を構築するための
ビルドスクリプトなどを提供する。
プルリクエストの作成、マージのタイミングで、
対象ブランチ用の実行環境を自動構築させる等。
リポジトリ ルートの構成
その他必要なテスト
machine-destroyer.yml
machine-builder.yml
Slide 24
Slide 24 text
レコメンドサービス(機械学習)
recommend/
学習モジュール
learning/
クリーンアーキテクチャに沿ったパッケージ構成/
〜.go
go.mod
Dockerfile
Makefile
リポジトリ service配下の構成 (例)
結果出力モジュール
result/
モジュール単位の
ビルドやテストは、
モジュールの中身で
完結させる。
学習モジュールと同様
Slide 25
Slide 25 text
ハードル
を
下げる
スケール
を
続けられる
リトライ
できる
Slide 26
Slide 26 text
アーキテクチャを
ツールとして利用し
システム開発を総合的に支援する
Slide 27
Slide 27 text
まとめ : ハードルを下げる
● Go
○ 始めやすさ、習得しやすさ
● マイクロサービスアーキテクチャ
○ 変更の影響を狭め、チームの開発・運用に対するハードルを下げる
■ 設計者のハードルは上がる、チームの知識拡充はミッションとなる
● モノレポ
○ 隣のサービスのコードが既に手元にあり、見通しが良い、参考にしやすい
○ プロジェクト横断的な機能の提供が容易
● クリーンアーキテクチャ
○ マイクロサービス、モノレポとの相乗効果、隣のサービスの全体設計を参考可能
Slide 28
Slide 28 text
まとめ : スケールを続けられる
● Go
○ シングルバイナリという取り回しの良さが、マイクロサービスとの相性が良い
● マイクロサービスアーキテクチャ
○ 必要な箇所だけの、ビルドとデプロイ
● モノレポ
○ サービスが増えても、リポジトリ配下のディレクトリとファイルが増えるのみ
● クリーンアーキテクチャ
○ ビジネス要件等の変更による、柔軟な対応
Slide 29
Slide 29 text
まとめ : リトライできる
● Go
○ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い
● マイクロサービスアーキテクチャ
○ サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易
Slide 30
Slide 30 text
終了