物流プラットフォーム＆新バース管理システム
# 概要 全社的にプロダクトを作り直すこととなったため、そのアーキテクチャの設計、およびバース管理システムの作り直しを担当した。他社を巻き込むことを前提とした物流プラットフォームを構築することを目標とし、Goによってマイクロサービスを構築することとした。 # 技術スタック バックエンド: Go フロントエンド: React.js DB: MySQL (Amazon Aurora) その他: Amazon S3, Docker, Kubernetes # 物流プラットフォーム詳細 他社を含め多数のシステムを連動させることを目標としているため、マイクロサービスを採用した。また開発言語として、ローカルでのテストを高速に回せることを期待して軽量なGoを採用した。 インラフについてはKubernetesとIstioを使用したサービスメッシュを構築することにした。 実装のアーキテクチャについては、Clean Architectureの考え方を取り入れ、テスタビリティの高い方式を考案した。 私はユーザID管理の初期検討も担当した。複数プロダクトのSSOが必須であり、また、他社システムとの連携を見据え、OpenID Connectを使用することとした。 OpenID Connectサーバは自前で作らずにORY Hydraを使用し、ORY Hydraと連携するためのID Providerを実装した。 また、マイクロサービス間の認証やセッション管理、シングルサインイン・サインアウトの方式を設計した。 その後、各プロダクトのベースとなる物流プラットフォームの開発は後任に任せ、私は下記の新バース管理システムの開発に移行した。 # 新バース管理システム詳細 2018年に開発したシステムの完全なリプレイスをリーダーとして遂行した。 チームメンバは、開発・QA・ビジネスを合わせて8～12名。 フロントエンドとバックエンドを完全に分業とし、私は全体の管理とバックエンドを担当している。 社内外の他プロダクトと連携する予定であるため、設計がアプリケーションによりすぎないようにドメイン駆動によって開発を進めている。既存システムの運用で見えてきた課題から、ドメインエキスパートと協力してドメインモデルを再設計した。データ構造を見直したため移行時にシステムを止める必要が出てしまったが、将来の拡張性を考えてデータ構造の再構築を決断した。 ドメインを実装するサービスは完全にアプリケーションロジックから分離し、ドメインロジックはサービス、アプリケーションロジックはBFFに実装する構成とした。Clean ArchitectureにおけるEntitiesとUse Casesを別サーバに分ける構成である。 # 運用を通して見えた課題と対応 処理を汎用化するためにリフレクションを使用しているが、データ量（処理対象）が多い場合に処理速度が遅すぎるという問題が発生した。通常の画面で表示する程度の情報量であれば問題ないが、データ分析のための集計などでは体感できるほどであったため、データ量が多い場合はリフレクションを使わずにべた書きするように変更した。 また同様の問題として、使用しているORMであるGORMの処理速度にも問題があった。DBから取得したデータのGo構造体へのマッピングが遅く、オンラインで万単位のデータを処理することが難しかったため、データ量が多い処理では自前でマッピングするようにした。