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

Transcript

1. パフォーマンス改善を支える アーキテクチャの役割とは？
2. ©OPENLOGI Inc. 会社紹介 2
4. ©OPENLOGI Inc. 荷主と物流パートナーを結ぶプラットフォーム 倉庫会社 マテハン 配送会社 資材会社 物流パートナー 5社 3社 荷主 5,300社 Eコマースを含む アパレル/雑貨/IPグッズ /インフルエンサー/マッ トレス/越境など様々 データ分析/活⽤ ‧需給予測 ‧リスク評価 ‧マッチング ‧最適化 ネットワーク化 提携70社 （※準提携130社） 12社 （国内‧海外） サービス提供 ソリューション 稼働率向上 庫内DX化 物流課題の解決 （コスト削減/効 率化‧⾃動化/最 適拠点配置等） 物流パートナーをネットワーク化することで、ノンアセット型のフルフィルメントサービスを提供 倉庫や配送といったフィジカルなリソースを AWSのようなインフラに変⾰し、サービスから得られる データを分析/活⽤することで、社会課題である物流業界の⾮効率を解消します 4
5. ©OPENLOGI Inc. ビジョン実現のためのロードマップ 柔軟性の⾼い物流版AWSを実現し、将来的には配送やサプライチェーンを含めたコマース全体を最適化する “フィジカルインターネット”の世界観を⽬指して参ります 5 ECのグロース パートナー 倉庫 75社 従量課⾦ API連携 倉庫 1-2社 物流版AWS 倉庫 250社 フィジカル インターネット 倉庫 500社 倉庫NW拡⼤ 配送連携 倉庫 15社 • EC物流の原型 • メニュー化/標準化 • 多数荷主の⼀元管理 • 倉庫の空きスペースを 有効活⽤ • 在庫分散⇒コスト減 • 越境キャリアと連携 • EC事業の幅広いニーズ をカバー • ⾃動出荷率を向上 • マルチチャネル対応 • データ活⽤‧可視化 • ロボティクス化による オペレーション効率化 • ECの波動に対応 • モノの流れをデータで 捉え、究極に効率化 • 海外やSCM含めた コマース全体の最適化 フェーズ３ フェーズ４ フェーズ５ フェーズ１ フェーズ２
6. ©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日 プレスリリース
7. 自己紹介 7
8. ©OPENLOGI Inc. 自己紹介 deep-rain.com 2024年2月入社 CTO室所属 引当処理の改善に取り組んでいます。 どちらかといえば犬派です。 【経歴】 - 教育系事業会社 Software Engineer, 研究開発を経て、 Architectとしてアーキテクチャの価値に向き合う - 通信系事業会社 Architectとして、プロジェクト立ち上げの 0→1 のアーキテクチャを構築 - 個人事業 Sound Engineerとして 音楽のアーキテクチャに向き合う などなど、様々なアーキテクチャに向き合ってきた人生でした。
9. ©OPENLOGI Inc. 自己紹介 9 CTO室とは？ • 全社的な課題に向き合い、生産性を最大化するチーム • 重要機能や巨大機能のリファクタリング、リアーキテクチャなど、「機能開発」など のスコープからは外れる事柄を担当する • 技術的負債や、横断的課題を含め、抽象度、不確実性が高いテーマに向き合うこ とが多い
10. ©OPENLOGI Inc. 引当処理とは？ 10
11. ©OPENLOGI Inc. 引当処理とは？ 11 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 荷主 倉庫 お届け先
12. ©OPENLOGI Inc. 引当処理とは？ 12 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 荷主 倉庫 お届け先 ここの話をします！
13. ©OPENLOGI Inc. 引当処理とは？ 入庫イメージ A-1 A-2 B-1 B-2 C-1 D-2 D-1 D-3 商品A 商品B 商品C
14. ©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
15. ©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
16. ©OPENLOGI Inc. 引当処理とは？ 16 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 入庫 ピッキング 出荷 出庫指示 openlogi 荷主 入庫処理 引当処理
17. ©OPENLOGI Inc. 引当処理とは？ 引当ができないと…？ • 出庫指示された商品に在庫があるのか？ • どこからピックすればいいのか？ • そもそも出庫可能なのか？ わからない！ 何もできない！
18. ©OPENLOGI Inc. 引当処理とは？ 引当ができないと…？ 作業が進まない 経済的損失 信用の毀損 企業価値の毀損 配送遅延 機会損失
19. ©OPENLOGI Inc. 引当処理とは？ 引当ができないと…？ 地球がヤバい！ 物流という大動脈を止めてしまう。 つまり…
20. ©OPENLOGI Inc. 引当処理の現状と課題 20
21. ©OPENLOGI Inc. 引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと… この引当情報は引当可能なんだっけ …？ 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん
22. ©OPENLOGI Inc. Confidential （社外秘） 何が課題なのか？ 変更容易性 パフォーマンス 可読性 • DBに直接依存しているので、処理を読み解くのに必要な知識が莫大になる • トップレベルのエントリーポイントに詳細まで記述されており、全てを読み解かな いと意味のある知識を得られない • 実装に直接依存しているため、影響範囲が計り知れず、テスト等 QAに多大な 時間が掛かる • 依存の方向性が安定しておらず、安定させるべきモジュールとそうでないモ ジュールの区別がつかない • パフォーマンスに関する事柄を隠蔽できていないので、パフォーマンスチューニ ングそのものが可読性、変更容易性の悪化に直結してしまう 22 引当処理の現状と課題
23. ©OPENLOGI Inc. 引当処理の現状と課題 といった課題はあるものの、このアーキテクチャが悪い、というわけではありません。 どのようなコードやアーキテクチャでも、仕様に沿って動いているならそれは正しいですし、コードの良し悪しと いうものは目的に沿って語られるべきです。 ここまでの複雑性を持ったシステムで、振る舞いの価値を最大化し続けてきたのだから、 感謝と尊敬を忘れてはいけません。 先人は常に偉大です！
24. パフォーマンス改善とアーキテクチャ 24
25. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に向き合うために何が必要か？ Don’t think, Profile… はもちろんのことですが、その先、コードに変更を加える場合には、 変更容易性 が必要不可欠ですよね！
26. ©OPENLOGI Inc. （再掲）引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと… この引当情報は引当可能なんだっけ …？ 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん
27. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当する 引当完了を 知らせる 引当処理くん 引当可能な在庫調べるくん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 引当するくん 引当情報を 保存する 引当可能な 在庫を調べる 在庫情報くん 引当情報くん 引当完了お知らせくん 引当完了イベント メールを送信する Slackに通知する 引当受付 システムくん専用受付窓口くん 理想 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報Repoくん 在庫情報Repoくん モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例
28. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り アーキテクチャは、ソフトウェア全体の文脈で捉えられがちですが、 巨大化したソフトウェア全体のアーキテクチャを切り替えることは非常に困難です。
29. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り まずはモジュールを分離させ、小さい機能から少しずつ手を加えていくことで、少なくともそ の機能に関わる依存関係を整理していくことができます。 「大きな泥団子」に少し手を加えても「何か手が入った大きな泥団子」にしかなりませんが、 完全に分離させて別の役割を与えることで、それを「泥団子ではない何か」にすることができ ます。 ？ ？
30. ©OPENLOGI Inc. 引当する パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当完了 イベント 引当処理くん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 在庫情報くん 引当情報くん メールを送信 する Slackに通知 する 引当受付 現実 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報を 保存する モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例
31. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること 今回の例で言えば、「パフォーマンス改善」という分かりやすい目的があり、そのために変更 容易性を確保する必要がある状態でした。 DDDなどはドメインの純粋性や完全性に寄与しますが、パフォーマンスを勘案したとき、そ れらが両立できないことはDDD Trilemmaとして提唱されています。 Domain model purity vs. domain model completeness (DDD Trilemma)　 https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ 引用：
32. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること バランスの取れた状態より 目的に沿った状態を目指す Software Performance Modifiability, Readability Domain Purity Domain Completeness
33. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること 例えば、ActiveRecordパターンはDDDとしては扱いづらいですが… ActiveRecordパターンに比べ、Repositoryパターンにおけるパフォーマンス上のメリッ トが薄いため、インターフェースを切ることによって影響範囲を抑えつつ、あえてそのま ま使います。 在庫情報くん 引当情報くん 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 ドメインモデルではなくActiveRecordをそのまま取り回すのは、 DDD文脈ではデメリットが大きいですが …
34. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善にとってアーキテクチャを整えることの何が嬉しいのか？ • インターフェースを切り、アプリケーションの上位方針を明確化することで、処理の流れ を追いやすくなる • ストラングラーフィグパターンにより、比較的安全なリリースが可能になる • 様々な実装を差し替えることが可能になり、実験がしやすくなる • 依存の方向を揃えることにより、各モジュールの安定性と影響範囲が明確化される • インターフェースに仕様を定義することで、テストが容易になる 全ては継続的なパフォーマンス改善のため！
35. ©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善にとってアーキテクチャを整えることの何が嬉しいのか？ 10年の道のりを経てきたソフトウェアにとって重要なことは、 DDDやClean Architectureなどのパターンを駆使して アーキテクチャを綺麗に整えることではありません。 いかにして変更を簡単に出来るようにするか？ 将来に選択肢を残すことができるか？ この先の10年を乗り越えるために必要なこと とは何かを考え続けることが重要だと考えています。
36. 継続可能な構造価値 36
37. ©OPENLOGI Inc. 継続可能な構造価値 As a team アーキテクチャはどんなにシンプルに見えても、 知らない人からすれば大変難解です。 インターフェースの使い方、依存の方向、抽象化…など。 現在は自然と意識できていることかもしれませんが、構造の価値に目を向けるまでは、その メリットすら分からなかった時代もあったはずです。 コードを扱い、維持していくのは我々ではなく、開発者組織全体であるということを忘れては なりません。 我々は、コードを書くだけでなく、 それを維持し、発展させていく責任があります。
38. ©OPENLOGI Inc. 継続可能な構造価値 As a team パフォーマンス改善に伴う構造価値の創出は、そのきっかけでしかありません。 果てしなく、困難な道を、今、歩き始めたばかりなのです。
39. Are Hiring! We 39
40. ©OPENLOGI Inc. 物流の未来を、動かす