Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

パフォーマンス改善を支えるアーキテクチャの役割とは?

 パフォーマンス改善を支えるアーキテクチャの役割とは?

deep-rain

May 22, 2024
Tweet

More Decks by deep-rain

Other Decks in Programming

Transcript

  1. ©OPENLOGI Inc. 荷主と物流パートナーを結ぶプラットフォーム 倉庫会社 マテハン 配送会社 資材会社 物流パートナー 5社 3社

    荷主 5,300社 Eコマースを含む アパレル/雑貨/IPグッズ /インフルエンサー/マッ トレス/越境など様々 データ分析/活⽤ ‧需給予測 ‧リスク評価 ‧マッチング ‧最適化 ネットワーク化 提携70社 (※準提携130社) 12社 (国内‧海外) サービス提供 ソリューション 稼働率向上 庫内DX化 物流課題の解決 (コスト削減/効 率化‧⾃動化/最 適拠点配置等) 物流パートナーをネットワーク化することで、ノンアセット型のフルフィルメントサービスを提供 倉庫や配送といったフィジカルなリソースを AWSのようなインフラに変⾰し、サービスから得られる データを分析/活⽤することで、社会課題である物流業界の⾮効率を解消します 4
  2. ©OPENLOGI Inc. ビジョン実現のためのロードマップ 柔軟性の⾼い物流版AWSを実現し、将来的には配送やサプライチェーンを含めたコマース全体を最適化する “フィジカルインターネット”の世界観を⽬指して参ります 5 ECのグロース パートナー 倉庫 75社

    従量課⾦ API連携 倉庫 1-2社 物流版AWS 倉庫 250社 フィジカル インターネット 倉庫 500社 倉庫NW拡⼤ 配送連携 倉庫 15社 • EC物流の原型 • メニュー化/標準化 • 多数荷主の⼀元管理 • 倉庫の空きスペースを 有効活⽤ • 在庫分散⇒コスト減 • 越境キャリアと連携 • EC事業の幅広いニーズ をカバー • ⾃動出荷率を向上 • マルチチャネル対応 • データ活⽤‧可視化 • ロボティクス化による オペレーション効率化 • ECの波動に対応 • モノの流れをデータで 捉え、究極に効率化 • 海外やSCM含めた コマース全体の最適化 フェーズ3 フェーズ4 フェーズ5 フェーズ1 フェーズ2
  3. ©OPENLOGI Inc. 37.5億円 シリーズD資⾦調達を実施 ー 累計調達額65億円 6 〜テクノロジーとデータを活⽤した物流プラットフォームの構築を加速〜 調達の⽬的と今後の展開 さらなる事業拡⼤を図り、この度の調達資⾦は、エンジニア職‧

    ビジネス職を中⼼とした⼈材採⽤、及びプロダクト開発に充当する 予定です。物流業界内外から広く⼈材を募り組織基盤の強化に 取り組みます。 また、事業提携パートナーの強固なアセットを有効活⽤し、新規の 事業機会の追求を進め、物流の効率化、⾃動化、省⼈化を実現。 また倉庫ネットワークを活⽤した配送の効率化を⽬指します。 2024年問題という⽬下の社会課題の解消に貢献しつつ、 中⻑期的には企業の枠を超えた物流資産‧データを連携する 「フィジカルインターネット」を推進するために事業を 展開していきます。 オープンロジの採⽤について 事業拡⼤にともない、ビジネス職‧エンジニア職を中⼼に、 事業責任者、テックリード、プロダクトマネージャーなど様々な ポジションで採⽤を強化しております。 「テクノロジーを使い、サイロ化された物流をネットワーク化し データを起点にモノの流れを⾰新する」というオープンロジの ビジョンに共感し、実現を⼀緒に⽬指していける⽅のご応募を お待ちしております。 第三者割当増資 引受先 31VENTURES、Cygames Capital、東京海上ホールディングス、 HAKUHODO DY FUTURE DESIGN FUND、パーソルベンチャーパートナーズ、静岡キャピタル、あおぞら 企業投資、 Eight Roads Ventures Japan、Logistics Innovation Fund、SMBCベンチャーキャピタル 借入先 日本政策金融公庫、あおぞら企業投資、みずほ銀行、静岡銀行 ※2024年2月5日 プレスリリース ※2024年3月29日 プレスリリース
  4. ©OPENLOGI Inc. 自己紹介 deep-rain.com 2024年2月入社 CTO室所属 引当処理の改善に取り組んでいます。 どちらかといえば犬派です。 【経歴】 -

    教育系事業会社 Software Engineer, 研究開発を経て、 Architectとしてアーキテクチャの価値に向き合う - 通信系事業会社 Architectとして、プロジェクト立ち上げの 0→1 のアーキテクチャを構築 - 個人事業 Sound Engineerとして 音楽のアーキテクチャに向き合う などなど、様々なアーキテクチャに向き合ってきた人生でした。
  5. ©OPENLOGI Inc. 引当処理とは? 入庫イメージ 商品C A-2 B-2 C-1 商品C 商品C

    商品C 商品C 商品C 商品C 商品C 商品C 商品C 商品C A-1 B-1 D-2 D-1 D-3
  6. ©OPENLOGI Inc. 引当処理とは? 引当の例 商品Cが100個ほしい A-2 B-2 C-1 商品C 商品C

    商品C 商品C 商品C 商品C 商品C 商品C 在庫20 在庫20 商品C 商品C 在庫20 在庫15 在庫20 在庫20 A-1から40個 B-1から35個 D-1から25個 持ってくれば 足りるはず… A-1 B-1 D-2 D-1 D-3
  7. ©OPENLOGI Inc. 引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと…

    この引当情報は引当可能なんだっけ …? 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん
  8. ©OPENLOGI Inc. Confidential (社外秘) 何が課題なのか? 変更容易性 パフォーマンス 可読性 • DBに直接依存しているので、処理を読み解くのに必要な知識が莫大になる

    • トップレベルのエントリーポイントに詳細まで記述されており、全てを読み解かな いと意味のある知識を得られない • 実装に直接依存しているため、影響範囲が計り知れず、テスト等 QAに多大な 時間が掛かる • 依存の方向性が安定しておらず、安定させるべきモジュールとそうでないモ ジュールの区別がつかない • パフォーマンスに関する事柄を隠蔽できていないので、パフォーマンスチューニ ングそのものが可読性、変更容易性の悪化に直結してしまう 22 引当処理の現状と課題
  9. ©OPENLOGI Inc. (再掲)引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと…

    この引当情報は引当可能なんだっけ …? 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん
  10. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当する 引当完了を 知らせる

    引当処理くん 引当可能な在庫調べるくん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 引当するくん 引当情報を 保存する 引当可能な 在庫を調べる 在庫情報くん 引当情報くん 引当完了お知らせくん 引当完了イベント メールを送信する Slackに通知する 引当受付 システムくん専用受付窓口くん 理想 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報Repoくん 在庫情報Repoくん モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例
  11. ©OPENLOGI Inc. 引当する パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当完了 イベント

    引当処理くん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 在庫情報くん 引当情報くん メールを送信 する Slackに通知 する 引当受付 現実 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報を 保存する モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例
  12. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善にとってアーキテクチャを整えることの何が嬉しいのか? • インターフェースを切り、アプリケーションの上位方針を明確化することで、処理の流れ を追いやすくなる • ストラングラーフィグパターンにより、比較的安全なリリースが可能になる •

    様々な実装を差し替えることが可能になり、実験がしやすくなる • 依存の方向を揃えることにより、各モジュールの安定性と影響範囲が明確化される • インターフェースに仕様を定義することで、テストが容易になる 全ては継続的なパフォーマンス改善のため!
  13. ©OPENLOGI Inc. 継続可能な構造価値 As a team アーキテクチャはどんなにシンプルに見えても、 知らない人からすれば大変難解です。 インターフェースの使い方、依存の方向、抽象化…など。 現在は自然と意識できていることかもしれませんが、構造の価値に目を向けるまでは、その

    メリットすら分からなかった時代もあったはずです。 コードを扱い、維持していくのは我々ではなく、開発者組織全体であるということを忘れては なりません。 我々は、コードを書くだけでなく、 それを維持し、発展させていく責任があります。