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.5k
MediaDo DynamoDB活用事例/mediado-dynamodb-usecase
kenthamaguchi
0
1.3k
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
840
JAWS DAYS 2020 メディアドゥスポンサーセッション/jaws-days-2020-mediado
kenthamaguchi
1
1.9k
OOC 2020 メディアドゥ スポンサーセッション/ooc_2020_mediado
kenthamaguchi
0
580
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
530
Other Decks in Technology
See All in Technology
AIのための オンボーディングドキュメントを整備する - hirotea
hirotea
9
2.3k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
360k
RDRA3.0を知ろう
kanzaki
2
430
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
38k
Roo Codeにすべてを委ねるためのルール運用
pharma_x_tech
1
230
ソフトウェアテストのAI活用_ver1.10
fumisuke
0
240
MCP Clientを活用するための設計と実装上の工夫
yudai00
1
810
2025advance01
minamizaki
0
130
ローカル環境でAIを動かそう!
falken
PRO
1
170
コードの考古学 〜労務システムから発掘した成長の糧〜
kenta_smarthr
1
1.2k
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
240
S3 Tables を図解でやさしくおさらい~基本から QuickSight 連携まで/s3-tables-illustrated-basics-quicksight
emiki
2
340
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
81
9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The World Runs on Bad Software
bkeepers
PRO
68
11k
Scaling GitHub
holman
459
140k
The Language of Interfaces
destraynor
158
25k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.8k
GitHub's CSS Performance
jonrohan
1031
460k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
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 ◦ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い • マイクロサービスアーキテクチャ ◦
サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易
終了