Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy
Search
kent-hamaguchi
September 17, 2019
Technology
0
1.1k
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
メディアドゥ Go Conference 2021 スポンサーセッション/gocon-2021-mediado
kenthamaguchi
1
11k
メディアドゥ Amazon Personalize in AWS メディアセミナー Q1/mediado-amazon-personalize-aws-media
kenthamaguchi
0
1.1k
MediaDo DynamoDB活用事例/mediado-dynamodb-usecase
kenthamaguchi
0
1k
MediaDo.go #2 Clean Architectureとの付き合い方/mediado-go-2-clean-architecture
kenthamaguchi
2
1.6k
Infra Study Meetup #5 メディアドゥスポンサーセッション/infra-study-meetup-5-mediado
kenthamaguchi
0
650
JAWS DAYS 2020 メディアドゥスポンサーセッション/jaws-days-2020-mediado
kenthamaguchi
1
1.5k
OOC 2020 メディアドゥ スポンサーセッション/ooc_2020_mediado
kenthamaguchi
0
440
MediaDo.go #1 GopherCon 2019 参加レポート / mediado-go-1-gophercon-2019
kenthamaguchi
1
1k
Go conf 2019 spring, sponsor session "Go初導入の組織で、社内外へ貢献していくために実施した、2つのこと" / go-conf-2019-spring-sponsor-session-mediado
kenthamaguchi
1
440
Other Decks in Technology
See All in Technology
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
ohbarye
3
240
ChatGPT for IT Service Management (IT Pro)
dahatake
2
180
〜小さく始めて大きく育てる〜データ分析基盤の開発から活用まで
kniino
0
2k
最近たまに見かけるTiDBってなんだ? - Findy
pingcap0315
2
600
クラウドサインにおけるプロダクトマネージャーの役割と開発プロセス / 20240410_cloudsign-PdM
bengo4com
1
680
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
150
WebアプリケーションにおけるPDOの使い方入門 / phpcon odawara 2024
meihei3
2
430
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.4k
TransitGatewayの基礎
toru_kubota
0
230
複雑な構成要素を持つUIとの向き合い方 〜新・支出グラフでの実例〜 / B43 TECH TALK
nakamuuu
0
100
少数チームで挑む: SwiftUI, TCA, KMPを用いた 新規動画配信アプリ 「ABEMA Live」の開発について
tomu28
0
540
株式会社EventHub・エンジニア採用資料
eventhub
0
1.9k
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
67
8.6k
Optimising Largest Contentful Paint
csswizardry
7
2.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
6
990
Teambox: Starting and Learning
jrom
128
8.4k
Happy Clients
brianwarren
91
6.4k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Designing for humans not robots
tammielis
247
25k
Statistics for Hackers
jakevdp
789
220k
A better future with KSS
kneath
231
16k
The Pragmatic Product Professional
lauravandoore
24
5.8k
Creatively Recalculating Your Daily Design Routine
revolveconf
209
11k
From Idea to $5000 a Month in 5 Months
shpigford
377
45k
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 ◦ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い • マイクロサービスアーキテクチャ ◦
サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易
終了