Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy
kent-hamaguchi
September 17, 2019
Technology
0
600
MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy
kent-hamaguchi
September 17, 2019
Tweet
Share
More Decks by kent-hamaguchi
See All by kent-hamaguchi
kenthamaguchi
2
520
kenthamaguchi
0
150
kenthamaguchi
0
510
kenthamaguchi
0
71
kenthamaguchi
1
550
kenthamaguchi
1
300
kenthamaguchi
0
370
kenthamaguchi
2
680
kenthamaguchi
1
450
Other Decks in Technology
See All in Technology
texmeijin
1
370
hmatsu47
0
170
meteatamel
0
410
kenya888
1
140
koba789
0
450
i35_267
0
260
hgsgtk
4
800
nwiizo
1
160
nihonbuson
2
2k
fujiihda
8
1.2k
indigo13love
2
420
chaspy
2
770
Featured
See All Featured
colly
187
14k
lemiorhan
627
43k
jponch
103
5k
dotmariusz
94
5.1k
wjessup
338
16k
paulrobertlloyd
71
3.6k
chriscoyier
145
19k
jlugia
216
16k
jasonvnalue
82
8.1k
jnunemaker
PRO
40
4.6k
philnash
8
500
rasmusluckow
318
18k
Transcript
レガシーに立ち向かう アーキテクチャ選定への道のり
モジュール や パッケージの構成 チーム開発 や アーキテクチャの話
Go Conference 2019 Spring メディアドゥによるスポンサーセッションで話した内容。 • システム統合を進めている • 既存のシステムはモノリシックで変更に強くない •
将来的にはオンプレからクラウドに移す • どのように大胆なシステム対応を乗り切るのか
Go Conference 2019 Spring
方針 A : 今のシステムをそのまま改修する B : 新しいシステムを作る
方針 A : 今のシステムをそのまま改修する B : 新しいシステムを作る C : 漸進的に変えていく
概念的 イメージ : フェーズ 1 既存システム モノリシック 新規システム マイクロ オンプレ
クラウド AWS Java PHP Go PostgreSQL Storage DynamoDB S3 機能切り出し (開発) 互換データ提供 (運用)
概念的 イメージ : フェーズ 2 既存システム モノリシック 新規システム マイクロ クラウド
AWS Java PHP Go PostgreSQL Storage DynamoDB S3
概念的 イメージ : フェーズ 3 新規システム マイクロ クラウド AWS Go
DynamoDB, RDS S3, EFS
Go の強みを活かし続ける仕組みづくり
作戦 チームは全員新しくシステムを立ち上げるのは初めてであり、戦略が必要。 • 開発・運用の物理的・心理的なハードルを下げる • スケールを続けられる仕組みを作る • リトライできる仕組みを作る
手法 • Go • マイクロサービスアーキテクチャ • モノレポ • クリーンアーキテクチャ
関心事の分離 と 効率化 は 相反する要素
Go 大規模開発から、スモールスタートにも適した言語である。 • 学習コストが低い • シングルバイナリにまとまるため、コンテナベースの運用と相性が良い • エラーハンドリングや、テスト等、コミュニティ全体で文化の共有が活発 • Go
Modules、Go Proxy 等、エコシステムは利便性が高く、堅牢である
マイクロサービスアーキテクチャ 定められたサービス境界の中に、開発の影響を抑え込む。 • データベーススコープはまとめる、実質はサービスベースアーキテクチャ • 最初からマイクロサービスにするというのは、アンチパターンだが・・・ ◦ 今回について言えば、散々運用したレガシーシステムが対象 ◦ 辛い部分が分かっているため、その背景を元にサービス分割が可能
• 外部ライブラリへの依存、コード変更の影響をシステム全体に波及させない
モノレポ サービス横断的な機能の提供を効率化し、設計文化を共有する。 • チームの人数は多くない ◦ 全員が新卒入社の社員 ◦ 8年目 1人(濱口)、4年目 1人、3年目
1人、2年目 2人 • リポジトリの数は、その数に比例して管理や把握が重荷となる ◦ コードもサービスの数も把握が難しくなりがち • サービス全体で共通する機能の開発を効率化する
モノレポの課題 更新対象のサービスのみをビルド・デプロイ仕組みが必要。 • CI/CD の処理時間が積み上がり、開発速度に悪影響を与える • 本番デプロイで無関係なサービスに対する、不要なデプロイが発生する
モノレポの課題の解決 CircleCI 等で細かな設定などが可能だが、今回はAWSで完結させている。 • CodeBuild はプッシュやプルリクエストの発行など、 Gitリポジトリのアクションに基づくトリガーを絞ることができる • 各種サービス用のディレクトリ配下に変更がある場合のみ、 対象のサービスのCI/CDを実行する
クリーンアーキテクチャ 実行方法、実行環境に依存しない、変更に強い設計にする。 • ビジネスロジックと、ソフトウェアを取り巻く環境を分離する ◦ 再利用可能、取り替え可能なパーツでアプリケーションを作る ◦ コンテナベース、サーバレス、どちらも対応可能な形にする ◦ ビジネス要件の変更に合わせた柔軟な対応を可能にする
クリーンアーキテクチャの課題 • チームで把握度が異なる場合の、コーチングと知識共有が難しい ◦ 実装に悩んで進みづらくなる ▪ パッケージの名前、細かい末端のパッケージの分け方に悩む ▪ インターフェイス、構造体の名前に悩む ◦
インターフェースが乱立させ、それをテストするためのモックも大量に発生する • 似た名称のファイル、パッケージ、インターフェイス、構造体が乱立し、 組みづらさを感じる
クリーンアーキテクチャの課題の解決 • マイクロサービスアーキテクチャで、 細かくサービス・モジュールを分けているため、 各モジュールプログラムの分量は小さくなる • リポジトリ全体を一つのクリーンアーキテクチャの分け方で書かず、 各サービスの中でクリーンアーキテクチャを実践する • そもそもクリーンアーキテクチャである必要すらない粒度であれば、
ある程度は立ち上げの速度を重視した、ストレートな設計を採用すれば良い
pkg go.mod /log, /error … etc ロギングやエラーハンドリングなど、 横断的に利用可能であり、 文化に関わる機能を提供。 service
go.mod サービス単位 パッケージ モジュール単位 パッケージ 〜.go 〜.go サービス境界毎にパッケージを作成し、 モジュール単位でプログラムが並ぶ。 サービス単位にCI/CDを実行する。 リポジトリ ルートの構成
test unit-test.yml unit-test.Dockerfile サービスを横断して、 全体の機能が正しく動作するか テストする機能を提供する。 build サービス全体を構築するための ビルドスクリプトなどを提供する。 プルリクエストの作成、マージのタイミングで、
対象ブランチ用の実行環境を自動構築させる等。 リポジトリ ルートの構成 その他必要なテスト machine-destroyer.yml machine-builder.yml
レコメンドサービス(機械学習) recommend/ 学習モジュール learning/ クリーンアーキテクチャに沿ったパッケージ構成/ 〜.go go.mod Dockerfile Makefile リポジトリ
service配下の構成 (例) 結果出力モジュール result/ モジュール単位の ビルドやテストは、 モジュールの中身で 完結させる。 学習モジュールと同様
ハードル を 下げる スケール を 続けられる リトライ できる
アーキテクチャを ツールとして利用し システム開発を総合的に支援する
まとめ : ハードルを下げる • Go ◦ 始めやすさ、習得しやすさ • マイクロサービスアーキテクチャ ◦
変更の影響を狭め、チームの開発・運用に対するハードルを下げる ▪ 設計者のハードルは上がる、チームの知識拡充はミッションとなる • モノレポ ◦ 隣のサービスのコードが既に手元にあり、見通しが良い、参考にしやすい ◦ プロジェクト横断的な機能の提供が容易 • クリーンアーキテクチャ ◦ マイクロサービス、モノレポとの相乗効果、隣のサービスの全体設計を参考可能
まとめ : スケールを続けられる • Go ◦ シングルバイナリという取り回しの良さが、マイクロサービスとの相性が良い • マイクロサービスアーキテクチャ ◦
必要な箇所だけの、ビルドとデプロイ • モノレポ ◦ サービスが増えても、リポジトリ配下のディレクトリとファイルが増えるのみ • クリーンアーキテクチャ ◦ ビジネス要件等の変更による、柔軟な対応
まとめ : リトライできる • Go ◦ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い • マイクロサービスアーキテクチャ ◦
サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易
終了