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.2k
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.4k
MediaDo DynamoDB活用事例/mediado-dynamodb-usecase
kenthamaguchi
0
1.2k
MediaDo.go #2 Clean Architectureとの付き合い方/mediado-go-2-clean-architecture
kenthamaguchi
2
1.8k
Infra Study Meetup #5 メディアドゥスポンサーセッション/infra-study-meetup-5-mediado
kenthamaguchi
0
810
JAWS DAYS 2020 メディアドゥスポンサーセッション/jaws-days-2020-mediado
kenthamaguchi
1
1.9k
OOC 2020 メディアドゥ スポンサーセッション/ooc_2020_mediado
kenthamaguchi
0
560
MediaDo.go #1 GopherCon 2019 参加レポート / mediado-go-1-gophercon-2019
kenthamaguchi
1
1.3k
Go conf 2019 spring, sponsor session "Go初導入の組織で、社内外へ貢献していくために実施した、2つのこと" / go-conf-2019-spring-sponsor-session-mediado
kenthamaguchi
1
510
Other Decks in Technology
See All in Technology
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
140
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
200
ClineにNext.jsのプロジェクト改善をお願いしてみた / 20250321_reacttokyo_LT
optim
1
1.3k
OCI見積もり入門セミナー
oracle4engineer
PRO
0
120
大規模プロジェクトにおける 品質管理の要点と実践 / 20250327 Suguru Ishii
shift_evolve
0
280
OPENLOGI Company Profile
hr01
0
61k
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
240
PostgreSQL Unconference #52 pg_tde
nori_shinoda
0
190
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
1
180
Compose MultiplatformにおけるiOSネイティブ実装のベストプラクティス
enomotok
1
210
Dapr For Java Developers SouJava 25
salaboy
1
130
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
920
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Making Projects Easy
brettharned
116
6.1k
Site-Speed That Sticks
csswizardry
4
450
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Docker and Python
trallard
44
3.3k
GitHub's CSS Performance
jonrohan
1030
460k
A better future with KSS
kneath
238
17k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Gamification - CAS2011
davidbonilla
81
5.2k
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 ◦ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い • マイクロサービスアーキテクチャ ◦
サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易
終了