Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy

kent-hamaguchi
September 17, 2019

MediaDo.go #1 レガシーに立ち向かう / mediado-go-1-vs-legacy

kent-hamaguchi

September 17, 2019
Tweet

More Decks by kent-hamaguchi

Other Decks in Technology

Transcript

  1. レガシーに立ち向かう
    アーキテクチャ選定への道のり

    View full-size slide

  2. モジュール や パッケージの構成
    チーム開発 や アーキテクチャの話

    View full-size slide

  3. Go Conference 2019 Spring
    メディアドゥによるスポンサーセッションで話した内容。
    ● システム統合を進めている
    ● 既存のシステムはモノリシックで変更に強くない
    ● 将来的にはオンプレからクラウドに移す
    ● どのように大胆なシステム対応を乗り切るのか

    View full-size slide

  4. Go Conference 2019 Spring

    View full-size slide

  5. 方針
    A : 今のシステムをそのまま改修する
    B : 新しいシステムを作る

    View full-size slide

  6. 方針
    A : 今のシステムをそのまま改修する
    B : 新しいシステムを作る
    C : 漸進的に変えていく

    View full-size slide

  7. 概念的 イメージ : フェーズ 1
    既存システム
    モノリシック
    新規システム
    マイクロ
    オンプレ クラウド AWS
    Java
    PHP
    Go
    PostgreSQL
    Storage
    DynamoDB
    S3
    機能切り出し
    (開発)
    互換データ提供
    (運用)

    View full-size slide

  8. 概念的 イメージ : フェーズ 2
    既存システム
    モノリシック
    新規システム
    マイクロ
    クラウド AWS
    Java
    PHP
    Go
    PostgreSQL
    Storage
    DynamoDB
    S3

    View full-size slide

  9. 概念的 イメージ : フェーズ 3
    新規システム
    マイクロ
    クラウド AWS
    Go
    DynamoDB, RDS
    S3, EFS

    View full-size slide

  10. Go の強みを活かし続ける仕組みづくり

    View full-size slide

  11. 作戦
    チームは全員新しくシステムを立ち上げるのは初めてであり、戦略が必要。
    ● 開発・運用の物理的・心理的なハードルを下げる
    ● スケールを続けられる仕組みを作る
    ● リトライできる仕組みを作る

    View full-size slide

  12. 手法
    ● Go
    ● マイクロサービスアーキテクチャ
    ● モノレポ
    ● クリーンアーキテクチャ

    View full-size slide

  13. 関心事の分離 と 効率化 は
    相反する要素

    View full-size slide

  14. Go
    大規模開発から、スモールスタートにも適した言語である。
    ● 学習コストが低い
    ● シングルバイナリにまとまるため、コンテナベースの運用と相性が良い
    ● エラーハンドリングや、テスト等、コミュニティ全体で文化の共有が活発
    ● Go Modules、Go Proxy 等、エコシステムは利便性が高く、堅牢である

    View full-size slide

  15. マイクロサービスアーキテクチャ
    定められたサービス境界の中に、開発の影響を抑え込む。
    ● データベーススコープはまとめる、実質はサービスベースアーキテクチャ
    ● 最初からマイクロサービスにするというのは、アンチパターンだが・・・
    ○ 今回について言えば、散々運用したレガシーシステムが対象
    ○ 辛い部分が分かっているため、その背景を元にサービス分割が可能
    ● 外部ライブラリへの依存、コード変更の影響をシステム全体に波及させない

    View full-size slide

  16. モノレポ
    サービス横断的な機能の提供を効率化し、設計文化を共有する。
    ● チームの人数は多くない
    ○ 全員が新卒入社の社員
    ○ 8年目 1人(濱口)、4年目 1人、3年目 1人、2年目 2人
    ● リポジトリの数は、その数に比例して管理や把握が重荷となる
    ○ コードもサービスの数も把握が難しくなりがち
    ● サービス全体で共通する機能の開発を効率化する

    View full-size slide

  17. モノレポの課題
    更新対象のサービスのみをビルド・デプロイ仕組みが必要。
    ● CI/CD の処理時間が積み上がり、開発速度に悪影響を与える
    ● 本番デプロイで無関係なサービスに対する、不要なデプロイが発生する

    View full-size slide

  18. モノレポの課題の解決
    CircleCI 等で細かな設定などが可能だが、今回はAWSで完結させている。
    ● CodeBuild はプッシュやプルリクエストの発行など、
    Gitリポジトリのアクションに基づくトリガーを絞ることができる
    ● 各種サービス用のディレクトリ配下に変更がある場合のみ、
    対象のサービスのCI/CDを実行する

    View full-size slide

  19. クリーンアーキテクチャ
    実行方法、実行環境に依存しない、変更に強い設計にする。
    ● ビジネスロジックと、ソフトウェアを取り巻く環境を分離する
    ○ 再利用可能、取り替え可能なパーツでアプリケーションを作る
    ○ コンテナベース、サーバレス、どちらも対応可能な形にする
    ○ ビジネス要件の変更に合わせた柔軟な対応を可能にする

    View full-size slide

  20. クリーンアーキテクチャの課題
    ● チームで把握度が異なる場合の、コーチングと知識共有が難しい
    ○ 実装に悩んで進みづらくなる
    ■ パッケージの名前、細かい末端のパッケージの分け方に悩む
    ■ インターフェイス、構造体の名前に悩む
    ○ インターフェースが乱立させ、それをテストするためのモックも大量に発生する
    ● 似た名称のファイル、パッケージ、インターフェイス、構造体が乱立し、
    組みづらさを感じる

    View full-size slide

  21. クリーンアーキテクチャの課題の解決
    ● マイクロサービスアーキテクチャで、
    細かくサービス・モジュールを分けているため、
    各モジュールプログラムの分量は小さくなる
    ● リポジトリ全体を一つのクリーンアーキテクチャの分け方で書かず、
    各サービスの中でクリーンアーキテクチャを実践する
    ● そもそもクリーンアーキテクチャである必要すらない粒度であれば、
    ある程度は立ち上げの速度を重視した、ストレートな設計を採用すれば良い

    View full-size slide

  22. pkg
    go.mod
    /log, /error … etc
    ロギングやエラーハンドリングなど、
    横断的に利用可能であり、
    文化に関わる機能を提供。
    service
    go.mod
    サービス単位
    パッケージ
    モジュール単位
    パッケージ
    〜.go
    〜.go
    サービス境界毎にパッケージを作成し、
    モジュール単位でプログラムが並ぶ。
    サービス単位にCI/CDを実行する。
    リポジトリ ルートの構成

    View full-size slide

  23. test
    unit-test.yml
    unit-test.Dockerfile
    サービスを横断して、
    全体の機能が正しく動作するか
    テストする機能を提供する。
    build
    サービス全体を構築するための
    ビルドスクリプトなどを提供する。
    プルリクエストの作成、マージのタイミングで、
    対象ブランチ用の実行環境を自動構築させる等。
    リポジトリ ルートの構成
    その他必要なテスト
    machine-destroyer.yml
    machine-builder.yml

    View full-size slide

  24. レコメンドサービス(機械学習)
    recommend/
    学習モジュール
    learning/
    クリーンアーキテクチャに沿ったパッケージ構成/
      〜.go
    go.mod
    Dockerfile
    Makefile
    リポジトリ service配下の構成 (例)
    結果出力モジュール
    result/
    モジュール単位の
    ビルドやテストは、
    モジュールの中身で
    完結させる。
    学習モジュールと同様

    View full-size slide

  25. ハードル

    下げる
    スケール

    続けられる
    リトライ
    できる

    View full-size slide

  26. アーキテクチャを
    ツールとして利用し
    システム開発を総合的に支援する

    View full-size slide

  27. まとめ : ハードルを下げる
    ● Go
    ○ 始めやすさ、習得しやすさ
    ● マイクロサービスアーキテクチャ
    ○ 変更の影響を狭め、チームの開発・運用に対するハードルを下げる
    ■ 設計者のハードルは上がる、チームの知識拡充はミッションとなる
    ● モノレポ
    ○ 隣のサービスのコードが既に手元にあり、見通しが良い、参考にしやすい
    ○ プロジェクト横断的な機能の提供が容易
    ● クリーンアーキテクチャ
    ○ マイクロサービス、モノレポとの相乗効果、隣のサービスの全体設計を参考可能

    View full-size slide

  28. まとめ : スケールを続けられる
    ● Go
    ○ シングルバイナリという取り回しの良さが、マイクロサービスとの相性が良い
    ● マイクロサービスアーキテクチャ
    ○ 必要な箇所だけの、ビルドとデプロイ
    ● モノレポ
    ○ サービスが増えても、リポジトリ配下のディレクトリとファイルが増えるのみ
    ● クリーンアーキテクチャ
    ○ ビジネス要件等の変更による、柔軟な対応

    View full-size slide

  29. まとめ : リトライできる
    ● Go
    ○ 強力なエコシステムにより、外部パッケージの再取得や、ビルドの再現性が高い
    ● マイクロサービスアーキテクチャ
    ○ サービスがモジュール単位で構成されていれば、特定の機能のみの作り直しが容易

    View full-size slide