巨大インフラ産業で戦うSRE / SRE working in the large infrastructure industry

by m_norii (のりぃ)

Slide 1

Slide 1 text

巨大インフラ産業で戦うSRE 株式会社オープンロジ林正紀 SRE NEXT 2024 2024.08.03

Slide 2

Slide 2 text

©OPENLOGI Inc. 自己紹介 ● 林正紀 (Hayashi Masanori) ● X(Twitter)： @m_norii ● (株)オープンロジ技術開発部 SRE ● 2020年1月入社 ● 埼玉県川越市在住 ● 嫁とMr.Childrenと麻雀を愛するエンジニア

Slide 3

Slide 3 text

©OPENLOGI Inc.

Slide 4

Slide 4 text

©OPENLOGI Inc. 本日のAgenda ● 会社紹介 ● OPENLOGIとサービス信頼性 ● OPENLOGIのSRE ○ SREチームの取り組み① ○ SREチームの取り組み② ○ OPENLOGIのSREを振り返る ● SREチームの現在とこれから ● まとめ

Slide 5

Slide 5 text

©OPENLOGI Inc. おことわり本日の発表は、弊社でのSRE取り組み事例と SREにまつわる個人的な気づきを共有するものです。 SREとはこれだ！という唯一的なものを断言するものでもなければ他の会社の状況にフィットすることを保証するものでもありません。あくまで、いち企業いちエンジニアが、自身のコンテキストの中で SREを解釈し、取り組んだ事例としてお聞きいただければさいわいです。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

©OPENLOGI Inc. 会社概要・沿革会社名株式会社オープンロジ設立 2013年12月25日代表者代表取締役社長 CEO　伊藤秀嗣資本金 1億円住所東京都豊島区東池袋1-34-5 いちご東池袋ビル9階事業内容物流フルフィルメント・プラットフォーム「OPENLOGI」の開発、提供取引銀行みずほ銀行、りそな銀行、日本政策金融公庫、商工中金、あおぞら企業投資等社員数 192名（2024年7月時点）

Slide 8

Slide 8 text

©OPENLOGI Inc. 物流の未来を、動かす Mission テクノロジーを使い、サイロ化された物流をネットワーク化しデータを起点にモノの流れを革新する Vision １．悩まない物流荷主や倉庫が物流について悩まなくても良い状態を作る２．無駄のない物流荷主-倉庫-配送が連携しムダの少ない効率的な物流網を構築する３．物流から商流へ物流データを起点とした新しい商流網を構築する物流はこれから、テクノロジーがより浸透しダイナミックに変化するこれまでアナログだった物の流れがデジタルになり高効率化された未来が到達する物をつくる人とそれを欲しい人その間の物流や配送が全てネットワーク化され需要と供給が最適化される物流の進化から、経済が新たに活性化する次世代のインフラを作り、この時代の変革を物流に関わる多くの情熱たちと共に成し遂げる

Slide 9

Slide 9 text

©OPENLOGI Inc. オープンロジが目指す「遠くて高い山」「物流」という巨大な業界と「EC」という急成長・ハイポテンシャルな市場に切り込み、イノベーションを通じて、大きな社会的インパクトを実現したいと考えています物流業界 24兆円　　EC市場 14兆円（出典）EC化率。経済産業省資料/2022年時点日本 9.13% 中国 45.3% 米国 15.0% 世界 19.3% EC市場は長期で成長トレンドコロナ禍でも強い成長日本のEC市場は拡大余地が大きい巨大急成長ハイポテンシャル

Slide 10

Slide 10 text

©OPENLOGI Inc. サイロ化された物流課題物流業界では各社が連携できておらず、それぞれ部分最適を目指した結果、”サイロ化”が起きており、全体で見た場合には効率が悪いオペレーションが至るところで発生しています荷主 › 物流ノウハウがなく、やり方がわからない › 委託先の倉庫の良し悪しが分からない › 小ロットは敬遠され、固定費が掛かる › 倉庫間の連携がなく、波動対応が受けきれない › 現場がアナログで、データによる分析や生産性の改善が不在 › EC市場は成長するがドライバーが不足 →2024年問題（残業規制）が追い打ち › 積載効率が悪い（平均40％）倉庫配送デジタル化（DX化）とネットワーク化により、物流業界は大幅に合理化・効率化が可能

Slide 11

Slide 11 text

©OPENLOGI Inc. Whole Productの実現受発注、入出庫在庫、配送など一連のオペレーションと物流ネットワークが一体となったWhole Productとしてデータを中心に、物流をAWSのようなインフラに変革、荷主や物流パートナー双方の課題を解決します物流ネットワーク荷主オペレーション販売チャネル物流オペレーションデータ蓄積/分析

Slide 12

Slide 12 text

©OPENLOGI Inc. 荷主と物流パートナーを結ぶプラットフォーム倉庫会社マテハン配送会社資材会社物流パートナー 5社 3社荷主 5,300社 Eコマースを含むアパレル/雑貨/IPグッズ /インフルエンサー/マットレス/越境など様々データ分析/活用 ‧需給予測・リスク評価・マッチング・最適化ネットワーク化提携70社（※準提携130社） 12社（国内・海外）サービス提供ソリューション稼働率向上庫内DX化物流課題の解決（コスト削減/効率化・自動化/最適拠点配置等）物流パートナーをネットワーク化することで、ノンアセット型のフルフィルメントサービスを提供倉庫や配送といったフィジカルなリソースを AWSのようなインフラに変革し、サービスから得られるデータを分析/活用することで、社会課題である物流業界の非効率を解消します

Slide 13

Slide 13 text

©OPENLOGI Inc. オープンロジプラットフォーム「物流版AWS」をコンセプトとしたオープンロジプラットフォームには以下のような機能があり、物流の始まりから終わりまで、サプライチェーン全体を最適化するソリューションを提供します荷主向けシステム倉庫向けシステム受注連携システム請求清算システム分析ツール荷主が操作する入出庫管理システム・商品登録・入庫処理・出庫処理他倉庫作業者が操作する倉庫管理システム・入庫検品・出庫検品・ロケーション登録他 Shopifyなどの ECモールと連携商品の受注と連動しシームレスな商品管理を可能に荷主・倉庫双方の請求情報を管理するシステム・各種料金管理・集計処理・決済処理他荷主向けの分析ツール特定期間における様々なデータを把握することが可能経営的な判断をサポートオープンロジプラットフォーム

Slide 14

Slide 14 text

©OPENLOGI Inc. 技術開発体制技術開発 WMS 倉庫システム Billing 請求管理システム SRE インフラ/DevOps 基盤開発 Product Management Order Sync 受注連携システム Portal 荷主システム HHT ハンディターミナル Design QA Engineering Management 組織横断チーム CTO室負債解消 CRE データ基盤

Slide 15

Slide 15 text

©OPENLOGI Inc. アーキテクチャ ※使用しているスタックの一部を図示。実際のアーキテクチャとは多少異なります。

Slide 16

Slide 16 text

©OPENLOGI Inc. 技術スタック特定の技術に固執せず、課題を解決するために最適な技術を選定していますフロントエンドバックエンドデータストアインフラ/モニタリング CI/CD IaC

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©OPENLOGI Inc. EC事業者の業務〜物流の流れ楽天 Amazon Yahoo! Japan 工場/メーカー  フォワーダー  卸し会社  倉庫会社   入出庫業務  EC事業者   発注  生産  引き渡し  納品  通関業務  納品  配送会社   入庫の連絡   出荷依頼  出荷  配送  物流業務  顧客対応  仕入れ業務  問い合わせ対応（未着、返品、商品について）   販売業務  出店  自社  BASE

Slide 19

Slide 19 text

©OPENLOGI Inc. 倉庫内業務の流れ工場/メーカー   フォワーダー   卸し会社   倉庫会社   通関業務   出庫業務  保管業務  入庫業務  ①  ②  ③  ④  ⑤  ⑥  ⑦  ⑧  ①  ②  ③  ④  ⑤  ⑥  ⑦  倉庫着   デバンニング   着荷登録   作業台へ   入庫IDを読取る   開梱  入庫内容確認   外装＆数量検品   棚入れ   ⑨  ⑩  ハウスコード貼り   ①棚保管   ②パレット保管   ③ハンガーラック保管   棚卸し  ピッキングリスト出力   リストをとる   ピッキング   検品台へ   バーコード検品   ⑨  ⑧  梱包作業   送り状貼付   パレット積み   引き渡し   納品 

Slide 20

Slide 20 text

©OPENLOGI Inc. OPENLOGIのシステムに障害が発生すると… 工場/メーカー   フォワーダー   卸し会社   倉庫会社   通関業務   出庫業務  保管業務  入庫業務  ①  ②  ③  ④  ⑤  ⑥  ⑦  ⑧  ①  ②  ③  ④  ⑤  ⑥  ⑦  倉庫着   デバンニング   着荷登録   作業台へ   入庫IDを読取る   開梱  入庫内容確認   外装＆数量検品   棚入れ   ⑨  ⑩  ハウスコード貼り   ①棚保管   ②パレット保管   ③ハンガーラック保管   棚卸し  ピッキングリスト出力   リストをとる   ピッキング   検品台へ   バーコード検品   ⑨  ⑧  梱包作業   送り状貼付   パレット積み   引き渡し   納品 

Slide 21

Slide 21 text

©OPENLOGI Inc. OPENLOGIサービスと信頼性 ● EC事業者 ○ 入庫・出庫依頼ができない ○ 機会損失、エンドユーザへの信頼低下 ● 倉庫 ○ 入庫・出庫作業ができない ○ 商品をエンドユーザに配送できない ○ 倉庫作業員の手が止まってしまう ● 物流は経済の血液循環 ● リアルが絡むシステムは、障害発生時のインパクトが大きい ● 高い信頼性が求められる

Slide 22

Slide 22 text

Slide 23

Slide 23 text

©OPENLOGI Inc. SREチーム発足以前 ● (m_noriiが入社した2020年1月当時)エンジニアは18人 ○ うち、インフラ担当は3名 ● インフラチームは存在したが、言葉通りインフラ運用がメイン ● SRE的な活動も一部ではあったが当時はボーイスカウト的に気づいた人・得意な人が進めることが多かった（組織的に動けているわけではなかった）

Slide 24

Slide 24 text

©OPENLOGI Inc. 2022年4月：SREチーム発足 ● インフラチームから SREチームに名称変更する形で発足 ● 発足当時の社内資料：

Slide 25

Slide 25 text

©OPENLOGI Inc. SREチーム発足当時の個人的な想い ● よりサービスに向き合おう、というのはそれはそう ● とはいえ、この資料見る限り、今までとそんなにやること変わってない・・・？ ● SRE本※ で言ってるSREよりも範囲広い感じ？ ● SREって流行りだしな ● インフラ、よりもSREって言ったほうが採用や技術広報的にもいいのかな？ ※ O'Reilly Japan 「SRE サイトリライアビリティエンジニアリング」のこと

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 ● Datadogは導入していた ● 十分に活用できていなかった ● 一部、別システムも利用していた ○ CloudWatch ○ PaperTrail

Slide 28

Slide 28 text

©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化スロークエリの可視化 →致命的な問題になる前に発見、対処ができるように

Slide 29

Slide 29 text

©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 SLOの導入 →非同期処理の「なんとなく重い」が可視化　明確な基準で対処できるように

Slide 30

Slide 30 text

©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 Profiler の導入 →PHP実行関数単位での　処理時間の可視化 →ボトルネックになっていた　重いバッチ処理の改善に繋がる

Slide 31

Slide 31 text

©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 ● Datadogは導入していた ● 十分に活用できていなかった ● 一部、別システムも利用していた ○ CloudWatch ○ PaperTrail ● 監視基盤をDatadogに集約 ● ダッシュボード整備 ● SLI/SLO整備 ● Profiler導入

Slide 32

Slide 32 text

©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 ● 問題が発生したベースでアドホックに対応 ● パフォーマンス劣化がビジネスにも影響

Slide 33

Slide 33 text

©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善レイテンシーの改善 →特に処理時間がかかっていた　特定エンドポイントに対する処理が大幅に改善

Slide 34

Slide 34 text

©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善スロークエリの解消で、DBのレイテンシーも大幅改善 CPU使用率も安定するように

Slide 35

Slide 35 text

©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 ● 問題が発生したベースでアドホックに対応 ● パフォーマンス劣化がビジネスにも影響 ● Datadog整備により潜在的なパフォーマンスリスクを事前に検知 ● レスポンスタイムの改善 ● DB負荷の改善

Slide 36

Slide 36 text

©OPENLOGI Inc. SREチームの取り組み：IaC化 ● AWS、Datadog等 SaaSの設定は Webコンソールから ● 履歴が残っておらず後日、なんのために設定されたものかわからず困ることも ● Terraformを採用 ○ Datadog Monitor/SLO ○ GitHub ○ AWS

Slide 37

Slide 37 text

Slide 38

Slide 38 text

©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 ● 一部便利ツール的なものはあったが、体系立てて管理されていなかった ● インフラ/SREチームへ依頼ベースでの作業も多かった ● リリース手順が煩雑で、ミスも多かった

Slide 39

Slide 39 text

©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 QA用DB立ち上げ Before: エンジニアがチケット起票してSREに依頼 After: エンジニア自身でActionを実行

Slide 40

Slide 40 text

©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 Before: リリース担当がコマンドを逐次実行 (ミスも多かった) After: メンテ開始Action、デプロイAction、メンテ終了Actionを実行するだけデプロイ・リリースの自動化

Slide 41

Slide 41 text

©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 ● 一部便利ツール的なものはあったが、体系立てて管理されていなかった ● インフラ/SREチームへ依頼ベースでの作業も多かった ● リリース手順が煩雑で、ミスも多かった ● GitHub Actionsを活用し開発エンジニアで完結するように（セルフサービス化、認知負荷軽減） ○ QA環境立ち上げ ○ QA用DB立ち上げ ○ デプロイ・リリースの実行

Slide 42

Slide 42 text

©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 ● lint等の実行は開発者個々人任せだった ● UnitTestがある機能と無い機能が混在 ○ どのくらいテストが網羅しているのかもわかっていなかった

Slide 43

Slide 43 text

©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化各種LinterをCIに導入

Slide 44

Slide 44 text

©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 Code Climateの導入カバレッジ率の可視化 PR上でカバレッジの変化率を表示 PR上でCode Smellを指摘

Slide 45

Slide 45 text

©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 ● lint等の実行は開発者個々人任せだった ● UnitTestがある機能と無い機能が混在 ○ どのくらいテストが網羅しているのかもわかっていなかった ● 各種Linter等をCIに導入 ○ PHPStan ○ PHP CS Fixer ○ ESLint ○ Shellcheck ○ Secretlint ● CodeClimateを導入 ○ テストカバレッジを可視化 ○ 問題あるコード自動指摘 ● →開発生産性向上

Slide 46

Slide 46 text

Slide 47

Slide 47 text

©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション ● SREチームと関わりの深いチームと定期的にMtgを実施 ○ 開催頻度は関わり度合いにより異なる（週1〜月1） ● 各チームの課題をヒアリング課題の早期発見・早期解決を目指す ● SREチームとしての要望、導入して欲しい事の共有も実施 ● 取り扱う課題は「SREプラクティス」にこだわらない困っていることがあれば基本的に何でも聞く Sync Mtgの導入

Slide 48

Slide 48 text

©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション Collaboration: 頻繁に交流をし、課題把握・課題解決を密接に行っている Facilitation: 業務を推進するためのサポート、もしくは実作業を代わりに実施している X-as-a-Service: 一般的なチーム問い合わせ・依頼など、決まった手順を介してのやり取り他チームとの関係性

Slide 49

Slide 49 text

©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション ● 課題が発生するとその都度会議を招集 ● チームごとに課題を抱えがちだった ● 開発チームとSync Mtgを定期的に実施 ● 各チームと目線をあわせて「課題」に取り組めるようになった ● SREチームの取り組みが「組織・会社に貢献できている」という確信が得られた ● 他のチームも「孤独」だったことに気づいた ○ 誰に相談してよいか分からない悩みを抱えていた ○ オープンスタンスで話をする場の大事さを感じた

Slide 50

Slide 50 text

Slide 51

Slide 51 text

©OPENLOGI Inc. SREチームの取り組みを振り返ると… ● オブザーバビリティの強化 ● パフォーマンス改善 ● IaC化 ● GitHub Actionsによる自動化 ● コード品質強化および可視化 ● 他チームとのコラボレーション

Slide 52

Slide 52 text

©OPENLOGI Inc. Platform Enginnering Kaigi 2024より「Platform Engineering とSREの⾨」@nwiizo https://speakerdeck.com/nwiizo/platform-engineering-to-sre-nomen?slide=28 SREチームの取り組みを振り返ると…

Slide 53

Slide 53 text

©OPENLOGI Inc. SREチームの取り組みを振り返ると… ● オブザーバビリティの強化 ● パフォーマンス改善 ● IaC化 ● GitHub Actionsによる自動化 ● コード品質強化および可視化 ● 他チームとのコラボレーション Site Reliability Engineering Platform Engineering

Slide 54

Slide 54 text

©OPENLOGI Inc. OPENLOGIのSREチームの活動範囲 Site Reliablity Engineering Security Platform Engineering ※ Securityの取り組みについては当登壇では割愛しています

Slide 55

Slide 55 text

©OPENLOGI Inc. SREチーム発足当時の個人的な想い → 現在は ● よりサービスに向き合おう、というのはそれはそう ● とはいえ、この資料見る限り、今までとそんなにやること変わってない・・・？ ● SRE本で言ってるSREよりも範囲広い感じ？ ● SREって流行りだしな ● インフラチーム、よりもSREって言ったほうが採用や技術広報的にもいいのかな？ ● チーム名は大事 ○ 「運用だけのチーム」から「サービス信頼性に責任を持つチーム」に意識が変わる ○ 事業貢献への意識に繋がる ● SREといっても、取り組むべきプラクティスは各社の事情やフェーズで異なる ○ 思想や原則は大事 ○ プラクティスは参考にはすべきだが、各現場にフィットさせるのが重要方針に一定理解しつつも、斜に構えていた部分もあった

Slide 56

Slide 56 text

Slide 57

Slide 57 text

©OPENLOGI Inc. SREチームの基本方針 ● 横断的技術課題の解決によるビジネスへの貢献 ○ SRE チームなりのやり方でビジネスに貢献する ○ 以下の観点での貢献が可能と考えている     プラットフォーム機能向上処理能力が向上したり、使える機能が増える。結果サービスのUIUXや開発生産性向上に寄与する安定性向上よりシステムが安定的に動作することで、人手を介さずに自律的に長期的にシステムが運営できるようになる（費用削減も含む）セキュリティ向上セキュリティリスクが低減することで、サービス継続性に関わるリスクを減らすことができる開発生産性向上開発チームや組織全体の開発効率が向上し、よりビジネス価値を創造しやすくなる

Slide 58

Slide 58 text

©OPENLOGI Inc. SREチームの今後の課題 ● Deployment Pipeline の改善 ○ よりデプロイ回数を増やし、多様なリリースを行える環境の構築 ● コンテナをベースにしたアーキテクチャへの移行 ○ Container orchestration tool (ECS等) を用いたアプリケーション環境への移行 ○ 柔軟なコンピュートリソースの確保、デプロイ戦略の改善のため ● インフラのコードカバレッジの向上 ○ IaC, CaD (Configuration as Data) 関連のツールを組み合わせできる限りすべてのインフラ構成をコード化 ● セキュリティの堅牢化 ○ 日々刻々と変わる社会情勢、法関連の状況に即したインフラの改善 ● ミドルウェア・ソフトウェアの適切なバージョンアップ ○ 地味だがとても大事

Slide 59

Slide 59 text

©OPENLOGI Inc. より将来の成長に向けて (Beyond NEXT) ● 現状のOPENLOGIシステムのほとんどは、まだモノリスなアーキテクチャ ● 拙速なマイクロサービス化には舵を切らない決断を以前している ● しかし、将来のサービス成長を支えるためには、いずれ向き合わなければいけない課題 ● そのときにSREチームがボトルネックになってはいけない ○ SREはすぐにスケールできない ■ 採用の難しさ ● なので、OPENLOGIにもいずれなんらかの形の Embedded SRE的なロールが必要になるのでは ● 今はその将来を見越して、Platformをしっかり整備し、開発チームにSREの思想を啓蒙していくフェーズ

Slide 60

Slide 60 text

©OPENLOGI Inc. より将来の成長に向けて (Beyond NEXT) ● 「SLOはエンジニアのためだけのもの？」 ○ SLOは本来、経営・ビジネス層も活用できるポテンシャルがあるはず ○ 現在OPENLOGIのSLOは、システム寄りな指標のみ ○ Critical User Journeyに基づいたSLOの策定には踏み込めてない ○ Error Budgetも活用できていない ○ とはいえ、一足飛びに導入は難しい ■ 先にも述べたとおり、プラクティスありきではダメ ○ 組織の成長にあわせ、適切なタイミングで検討したい

Slide 61

Slide 61 text

Slide 62

Slide 62 text

©OPENLOGI Inc. まとめ ● OPENLOGIは、巨大な物流産業と急成長のEC市場をつなぐプラットフォームを開発・運用 ● リアルな「モノ」が動くシステムなので、サービスの信頼性が重要 ● OPENLOGIのSREチームは、以下の領域で活動し、事業に貢献している ○ サービス信頼性の向上 ○ Platform Engineering ○ セキュリティ ● 将来のさらなる事業成長に向けて、OPENLOGIのSREとしてよりあるべき姿を模索している

Slide 63

Slide 63 text

Are Hiring! We 現在急成長期で今がチャンス！全職種募集しています！ 63