製品・アドオン
PagerDutyの優位性
おすすめコンテンツ
PagerDuty Advance
PagerDuty Advance
重要なデジタルオペレーション業務における生成AI機能

オイシックス・ラ・大地様事例

オンプレミスにもPagerDutyを活用!
MSPからの移行でMTTA短縮化とコスト削減を実現したオイシックス・ラ・大地
インシデント管理を自分たちでコントロール。MSPからPagerDutyへの移行で平均確認時間 (MTTA) を約3分の1に
オイシックス・ラ・大地株式会社
従業員数
1,927名(2022年3月31日時点)
事業内容
ウェブサイトやカタログによる有機野 菜、特別栽培農産物、無添加加工食品 等、安全性に配慮した食品・食材を販売
所在地
〒141-0032 東京都品川区大崎一丁目11番2号 ゲートシティ大崎イーストタワー5F
取引期間
2018年~
  • 1001〜5000名
  • エンジニア負荷の軽減
  • 24/365サービスの実現
  • 小売業
  • MTTA・MTTR
PagerDuty導入前の課題
  • 24/365のサービス運営
  • インシデントの最速検知
  • エンジニアの負荷状況
PagerDuty導入効果
  • インシデントのMTTA(平均確認時間)を「10分」から「1分」へ
  • MTTR(平均修復時間)は1営業日以内に
  • エンジニアの負荷が大幅に軽減
  • データドリブンなインシデント再発防止が可能に

目次

    Oisix、大地を守る会、らでぃっしゅぼーやなど、食品宅配のサブスクリプション事業を提供するオイシックス・ラ・大地株式会社。企業理念「これからの食卓、これからの畑」のもと、食品の提供だけでなく、食品ロスの削減や農家支援なども展開している。物流を伴う事業のため、業務システムはオンプレミスとクラウドのハイブリッド構成となっており、インシデント対応の効率化のために「PagerDuty」を利用している。同社のシステム基盤部SREセクションマネージャーの林如弥(はやしゆきや)氏に、PagerDuty導入の経緯や現在のインシデント対応状況について聞いた。

    クラウドはもちろん、物流を支えるオンプレミス環境にPagerDutyを活用

     オイシックス・ラ・大地は、食品宅配のサブスクリプションを主な事業としており、有機野菜や特別栽培の野菜、できる限り添加物を使用せずに作った加工食品などを取り扱っている。社名からイメージできるように、複数の企業が統合してできた企業だ。2017年にオイシックス株式会社と株式会社大地を守る会が統合し、2018年にはらでぃっしゅぼーや株式会社が加わった。この経営統合最中である2018年1月からPagerDutyを利用しており、林氏も同じころ入社している。

     同社の従業員は2000人ほどで、そのうちエンジニア職は約100人。林氏が所属するシステム基盤部SREセクションには2023年1月現在11人のメンバーが在籍している。同社のエンジニア組織のカルチャーについて林氏は「セクションごとにかなり裁量があり、各セクションが掲げた理念に向かって仕事をしています。SREセクションは、社内で運用するシステムの信頼性に焦点を置き、より良くしていくことをミッションとしています」と語る。

     SREセクションの業務の一つがシステムの可視化。どこでどのような事象が起きて、今後どのように推移していくか、現在の状態は良好かどうかをテクノロジーによって可視化する。もう一つが自動化による効率化だ。人の手で行う繰り返し業務をソフトウェアで自動化する。これにはインシデント対応もあり、PagerDutyを使った自動化、効率化も行われている。林氏自身はマネージャーとして、システム全体を管理し、メンバーのフォローも行うなど、チームがうまく動けるような活動をしている。

     オイシックス・ラ・大地のITインフラは、オンプレミスとパブリッククラウドであるAWSのハイブリッド環境となっている。システム特性について林氏は「オンプレミスではお客様に食品をお届けする物流拠点のネットワーク機器が稼働しています。一方でパブリッククラウドではECサイトのシステムなどをAWSに置いています。サーバーは600台ほど運用しており、各システムは複数のモニタリングツールによって監視し、それらからのアラートをPagerDutyで受けてインシデント対応を行っている形です。PagerDutyには豊富なインテグレーションの機能があり、大抵の監視ツールを使っていてもオンプレミスやクラウドに関係なく連携ができ、適切な対応につなげられる安心感があります」と語った。

     システム運用体制上、PagerDutyが発するアラートを受けるのは、SREセクションの11人に加え、アプリケーション開発者やブランドごとのエンジニアなども含めた40人ほど。電話でのコール(オンコール)に待機するのはSREチームの8人から週次でプライマリ、セカンダリの2人が割り当てられる。なお、一部のアプリケーションについては直接開発者に割り当てており、コンテナ化され担当範囲が明確な場合があるからで、今後もオンコール先の分割と最適化を進めていく予定だ。

     モニタリングツールにおいてどのチームにどんなアラートを出すかを整理しPagerDutyを通じて発報する。林氏は「PagerDutyの優れた点がAPIキーごとに通知先をたくさん並べられることです。モニタリングツール側で切り分けを設定して、どこに通知するかをコントロールしています」と説明した。

    MSPからPagerDutyへの移行でMTTA(平均確認時間)は約30~50%改善し、コスト削減も実現

     PagerDutyの導入は、ちょうど林氏が入社したころにSREチームで検討していた。PagerDuty導入の背景として、当時はインシデント対応をMSP(マネージドサービスプロバイダ)企業に委託していたものの、柔軟な対応ができないという課題があったからだ。

    「MSP事業者の場合、たとえば、『今日はほかに用事があるので電話は受けられない』『休みなので対応できない』といった変更をいちいち連絡する必要があり、個々の対応もチケット制で煩雑でした。SNSなどを通じてPagerDutyの存在を知り、導入を検討することにしました。当時からPaerDutyはインシデント管理のサービスとして高いシェアを持っていたため、PagerDutyを導入するか、MSP事業者への委託を継続するかの二択でした」(林氏)

     PagerDutyへの移行によって、MTTA(平均確認時間)は約30~50%程度の改善を実現した。MSP事業者に委託していたころは、MSPの担当者側で、通知を受けてから手順書に従った判断するまでに15分~20分かかっていたが、10分未満に短縮している。また、コスト面でもインパクトがあった。MSP事業者の料金体系がサーバー台数に応じたものだったからだ。一方、PagerDutyはアカウント数に応じた料金のため、当時SREセクションの数名だけの利用となったことで、大きなコスト削減を実現した。

     インシデントの社内対応への移行の背景には、3社の経営統合もあった。各社で展開するブランドがあり、システムもそれぞれ異なる。インシデント自体も増加し、対応のための発報のやり方などもブランドのポリシーによって変わるため、きめ細やかなサポートが必要となる。

     「夜中でもすぐに対応してほしいというチームもあれば、システムが安定しているのでメッセージ通知のみで良いというチームもあります。多様なルールを整理してPagerDutyで最適化を続けています」(林氏)

    オンコール担当者のウェルビーングと助け合い文化を実現する「優しさのOverrides」機能

     現在、各チームの要求に対応するPagerDutyの最適化が行われているが、それに至るまでには時間を要した。そのきっかけは2021年7月に実施したメインのデータベース移行だ。移行に伴い、より細かなイベントを監視するためモニタリングツールを変更した。すると監視対象が広範囲になり、アラートの発報が増えてしまった。そこで、SREセクションでは発生するインシデント情報を蓄積しながら地道に最適化を行っていった。

     「オンコール担当は、夜中に2~3回電話で起こされることもありました。週に何度もあるとかなりきつくなります。なんとか改善したいという思いで取り組みました。毎週月曜にチームミーティングを行い、集まったインシデントを一つひとつ見ながら、どう処理するかを話し合って設定していきました。半年から1年弱の期間はかかりましたが、夜中に起こされる回数も激減しました」(林氏)

     PagerDutyでの自社運用に移行して訪れた変化に、通知の柔軟なコントロールによる恩恵がある。従来は電話とメールだけだったが、PagerDutyのスマートフォンアプリで個々のメンバーが柔軟に設定できるため、担当者のストレスが軽減された。林氏はPagerDutyアプリで重宝している機能として「Snooze」「UrgencyUseCase:SupportHours」「Overrides」を挙げた。

     Snoozeは、状況に応じてインシデントを一定期間保持し、対応を後回しにできる機能。移動や会議などですぐに対応できないときや、サイトの負荷がかかることがわかっている時間帯、業務時間外で翌日対応すればいいようなときに使う。UrgencyUseCase:SupportHoursは、対応可能な日時を指定して、その時間帯は通知に気付きやすくして、それ以外の時間帯は控えるというもの。

     林氏が最も気に入っている機能がOverrides。これは、オンコールの担当を上書きする機能だ。林氏は「週次のオンコール担当が割り当てられていても、前日の深夜に起きて対応したようなメンバーがいたら、その代わりにほかの人を割り当てることができます。私はこれを『優しさのOverrides』と呼んでいます。オンコールの負担をチームで分散できる素晴らしい機能です」と説明した。

    PagerDutyをさらに使いこなして、インシデント対応の自動化を目指す

     オンプレミスとパブリッククラウドのハイブリッド環境でシステムを運用しているオイシックス・ラ・大地は、従来アウトソースしていたインシデント対応をPagerDutyによって社内のメンバーで対応できるようにした。以前は週に何度も深夜対応しなければならないこともあったSREチームであったが、細やかな最適化の甲斐あって深夜対応は月に1度程度まで減った。

     林氏は「PagerDutyはオンプレミスやクラウドに関係なく、通知先を設定して最適化できるツールです。メンバーのみんなも『オンコール対応が怖くなくなった』と言っています」と成果を語った。

     SREチームの今後の展望として、林氏は、インシデントの自動回復にチャレンジしたいと答え、PagerDutyへの期待を込めて次のようにコメントした。

     「インシデントが起きた際、自動的に修復されるのが理想です。PagerDutyが自動診断や自動修復などができるジョブスケジュールツールのRundeckを買収したので、その機能を使ってみたいと思います。たとえば、当社のシステムはJavaで開発されていて、メモリ容量が足りず処理が止まってしまったときに再起動する必要があるのですが、これを自動化できるといいなと思っています。AI機能も気になっていて、これまでのアラートの傾向から自動で判断して処理をするなど、メンバーの負担を減らす機能も使ってみたいです」(林氏)