日本企業における6つのSRE事例と4つの成功ポイントとは

はじめまして、エンジニアスタイル編集部です！

コラムページでは、ITフリーランスに向けてお役立ち情報を発信します。Twitterではホットな案件を紹介してまいりますので、ぜひフォローをお願いいたします！
本記事が、皆様の参考になれば幸いです。

経験がまだ少ない方にもわかりやすく説明するために、初歩的な内容も記載しております。記事も長いので、実務経験豊富な方は、ぜひ目次から関心のある項目を選択してください。

エンジニアスタイルは、最高単価390万円、国内最大級のITフリーランス・副業案件検索サービスです。SREのフリーランス・副業案件一覧をご覧いただけますのであわせてご確認ください。

SRE組織を立ち上げた具体的な会社と事例とは

SRE組織を立ち上げた具体的な会社と事例について解説していきます。

株式会社メルカリ

メルカリは、フリーマーケットアプリを運営する企業として知られていて、多くのユーザーが日々取引を行っています。そのため、システムの安定性と利用可能性は極めて重要といえます。

SREチームの立ち上げは、システムのスケーラビリティと信頼性を確保し、エンジニアが新しい価値を生み出す開発に専念できる環境を提供することを目的としています。

さらに、SREチームはシステムの信頼性とパフォーマンスを向上させるために、インフラストラクチャの自動化、障害時の迅速な対応、システムの監視・アラートの最適化などを行っています。

メルカリグループには複数のSREチームが存在し、特にメルカリ自体にはMicroservices SREをはじめとするいくつかのSRE/インフラ関連のチームがあります。

これらのチームは、インシデントが発生した際に迅速に連携し、サポートを提供しながら問題の早期解決を目指しており、近年はメルペイSREチームやPlatformチームと協力して、PlaybookとRunbookの導入に注力しています。

Playbookはインシデント対応の運用手順書で、各Alertに関するガイドブックのようなものであり、連絡先やエスカレーション情報も含まれています。

一方、Runbookは特定の手順やツール、コマンドに特化したもので、特定のマイクロサービスや担当者の情報は含まれていません。

Playbookが全体のガイドブックであるのに対し、Runbookはその中の具体的な手順やツールを示すリンク先として位置づけられており、再利用性が高まっています。

LINE株式会社

LINEは、メッセージングアプリを中心に、様々なサービスを展開している企業です。数億人以上のユーザーが利用するLINEアプリは、24時間365日途切れることなくサービスを提供し続ける必要があるため、SREチームがシステムの安定性を確保し、サービスの品質を高めるために活動しています。

LINE株式会社におけるSRE（Site Reliability Engineering）について、VerdaはLINEのプライベートクラウドであり、Verdaの信頼性エンジニアリングチーム（VRE）がこのプラットフォームのためのSRE活動を担当しています。

このチームは日本と韓国に拠点を置いており、クラウドインフラストラクチャの開発と運用、特にサーバーやOSのような比較的低レイヤーの部分に対するSREを担当していて、主なミッションは、OSレベルでのトラブルシューティング、クラウドリソースのキャパシティ管理、および物理リソースの調達に関連する運用の改善を含んでいます​​。

チームは日本と韓国の2か所に分かれており、日本には5名、韓国には3名のメンバーがおり、合計8名のメンバーで構成されています。チームの責任は、信頼性エンジニアリング、モニタリング、およびIaaSドメインのデプロイメントシステムの開発を含んでおり、各メンバーには大まかに役割が割り当てられています。

特に、IaaSに関しては、60,000以上のVMと約20,000台の物理サーバーが使用されており、運用のコストは非常に大きいです。このコストを自動化と安定化を通じて削減することがVREの重要なミッションとされています。

また、モニタリングやデプロイメントのサービスが大規模であるため、システムをできるだけ統一することによって、管理のコストと開発者向けの機能の実装コストを削減しようとしています​​。

株式会社ヌーラボ

ヌーラボは、オンラインプロジェクト管理ツール「Backlog」やチャットツール「Typetalk」を提供している企業で、ヌーラボでは、多くのユーザーに対して安定したサービスを提供するため、SREチームがシステムの信頼性を確保する活動を行っています。

株式会社ヌーラボは、SRE課の設立後、SRE主導での改善活動のスピードが向上していますが、その具体的な例として「Backlogの課題検索機能のリプレイスプロジェクト」が挙げられます。

このプロジェクトは2019年8月から2020年2月にかけて実施され、SREと開発者が協力して要件定義からリリースまでを担当しました。この機能の問題点は以前から認識されていましたが、SRE課の設立後に具体的な改善が始まり、リプレイス後もSRE課は継続的な改善を進めています。

Backlogの課題検索機能は、ユーザー数の増加に伴い、スケーラビリティや可用性、ハードウェアコスト、運用コストといった問題が発生していたため、SRE課の目標は、モノリシックなアプリケーションを分割し、開発チームごとの責任範囲を明確にすることとしていました。リプレイスプロジェクトではAmazon Elasticsearch Serviceを採用し、多くの問題が解決されています。

プロジェクトの進め方としては、SRE課からの提案に基づき、小さなプロジェクトチームでスクラムのイベントを採用して進められ、リプレイス後のシステムではスケーラビリティや可用性の問題が解消され、ハードウェアコストや運用コストも削減されています。さらに、アプリケーションサーバーのコンテナ化や分割が容易になっています。

SRE課では、一度改善した機能に問題が発生した場合、その問題をプロダクトバックログに追加し、優先度を議論して継続的な改善を進め、現在も課題検索機能のElasticsearchクラスタのデータノードのインスタンスタイプの変更などの改善活動が進行中となっています。

株式会社エウレカ

株式会社エウレカは、マッチングアプリ「Pairs」を運営する企業として知られています。高いトラフィックとユーザーの期待を持つサービスを提供するため、SREの役割は非常に重要です。エウレカのSREチームは、システムのダウンタイムを最小限に抑えるための監視、アラート、自動化の取り組みを行っています。

エウレカのSREチームは、2016年に技術基盤チームとインフラチームの融合により設立されましたが、このチームの設立のきっかけは、当時のリーダー恩田がオライリーのSREに関する書籍に触れたことで設立されました。

SREの役割は多岐にわたるため、エウレカではチームのミッションや存在意義を明確に定義しました。その主な目的は、99.95%の可用性の確保、セキュリティリスクの撲滅、運用の自動化、キャパシティプランニングの最適化、リリースエコシステムの改善と安定化、技術サポートの提供などです。

具体的な取り組みとしては、SLO/SLIの定義、IaCの適用、インフラのスケーラビリティ確保、サーバーレス化、デプロイパイプラインの整備、データベースの最適化、監視・モニタリングの強化などが挙げられ、他にも障害対応のフローの構築や、障害時の対応をスムーズにするための仕組みの導入も行われています。

株式会社リクルートテクノロジーズ

リクルートテクノロジーズは、リクルートグループのITソリューションを提供する企業です。多岐にわたるサービスを持つリクルートグループのバックボーンとして、SREの取り組みは極めて重要といえます。

リクルートテクノロジーズは、2014年からインフラの自動化と迅速化を目的としたSREの取り組みを開始し、2017年に正式なSRE部を設立しました。この取り組みは、大手企業としては早い時期のもので、リクルートの技術革新への積極的な姿勢が背景にあります。

リクルートのデジタルサービスの大部分はオンプレミスで構築・管理されており、時代ごとの技術変化に合わせてインフラの更新・最適化が行われてきました。

所属するリクルートテクノロジーズのサイトリライアビリティエンジニアリング部の河村氏によれば、リクルートテクノロジーズのインフラ部門は、各事業会社のサービスに横断的に機能を提供していますが、サービスごとの要件の違いに対応するのが難しくなりました。そのためSREの概念を取り入れ、サービスの方向性を理解しながらオペレーションを進める必要があるとのことです。

インフラとアプリケーションの間の壁を越えて、より良いサービスを提供するための協力が不可欠であるとの考えから、SREの取り組みが強化されています。

株式会社エイチームライフデザイン

エイチームライフデザインは、不動産やライフスタイルに関連する多岐にわたるサービスを提供しています。彼らのITインフラは、ユーザーの日常生活に密接に関わるサービスを提供するため、高い可用性が求められます。

株式会社エイチームライフデザインは、従来フルスタックエンジニアがサイト開発を担当していましたが、今年SREチームを設立し、インフラ・運用を中心に担当するようになりました。

事業の拡大とともにサービス規模が増え、運用の限界が見え始めたためエンジニアの数が増える中で開発速度の差が生まれ、VPSからクラウドへの移行やモチベーションの問題も浮上しました。

SREの導入は、開発効率の最大化とエンジニアの疲弊を防ぐための戦略的な選択であり、SREの真の意味を理解し、その意図を学ぶことを重視しています。

SREの活動は、インフラの維持・管理、運用の自動化、基盤開発などを含むものとして位置づけられており、SREの導入後、エンジニアや事業、サイトに対する優しい活動が増え、全体の整理が進んでいるようです。

SRE組織を立ち上げる際に必要な4つのポイント

SRE組織を立ち上げる際に必要な4つのポイントについて解説していきます。

「理想的なSRE」を知る・定義する

SRE（Site Reliability Engineering）の組織を立ち上げる際の最初のステップは、何を目指すのか、すなわち「理想的なSRE」とは何かを明確に知り、定義することです。

例えば、GoogleのSREの原則や実践を参考にすることができますが、それだけでは不十分で、各企業やプロジェクトには独自のニーズや文化があります。

したがって、自社のビジネス要件や技術的な課題、組織文化に合わせてSREの役割や責任をカスタマイズする必要があります。

具体的には、サービスのSLI（Service Level Indicator）やSLO（Service Level Objective）を定義し、それに基づいて運用や開発のプロセスを最適化することが求められます。また、理想的なSREの姿を明確にすることで、チームのビジョンやミッションを共有し、組織全体のモチベーションを高めることができます。

スモールスタートする

SREの導入は、大規模な変革を一度に試みるのではなく、スモールスタートから始めることが効果的です。

初めに小さなプロジェクトやサービスを対象にSREを導入し、その結果やフィードバックを基に徐々に範囲を拡大していくアプローチがおすすめです。

例えば、ある特定のサービスの障害率を減少させるための取り組みや、一部のインフラの自動化を先に行うなど、具体的な課題を持ってスタートすることが重要です。

このスモールスタートにより、組織の中でSREの価値を実感しやすくなり、組織全体の協力を得やすくなります。また、初めの段階での成功体験は、組織全体のモチベーション向上や、次のステップへの布石となります。

SRE人材の採用を進める

SRE組織を立ち上げる際には、専門的なスキルセットを持った人材の採用が不可欠です。

SREはシステムの信頼性を高めるために、システム管理とソフトウェアエンジニアリングのスキルをバランスよく持っていることが求められます。

求人広告を設計する際には、求めるスキルセットを明確にし、求職者が求めるポジションの期待を理解できるようにすることが重要だといえます。

システム管理、ネットワーキング、プログラム能力、トラブルシューティング、そして優れたコミュニケーションスキルは、SREとして成功するために非常に重要です。

採用プロセスが進むにつれ、候補者の技術的知識と経験を評価するだけでなく、チームと文化に適合するかどうかも評価することが重要になります。

また、新しいSREのオンボーディングとトレーニングは組織の成功にとって重要な項目です。

Googleでは新入社員向けの徹底したオンボーディングプログラムを提供しており、これにより新人はGoogleのエンジニアリング文化と技術スタックを迅速に理解することができるようになります。

さらに、明確なキャリアパスを提供することで、エンジニアは長期的に組織に留まり、持続的に貢献する理由を持てるようになるといえます。

他社のSRE組織の立ち上げをヒアリングする

他社のSRE組織の立ち上げや運用の経験をヒアリングすることは、自社のSRE組織構築の大きな手がかりとなります。

例えば、LinkedInでは、SREチームがサービスの信頼性とパフォーマンスを向上させるために、様々な内部ツールを開発していますが、彼らの取り組みやツールの詳細を学ぶことで、自社のツール開発のアイデアを得ることができます。

また、LINEでは、SREチームがシステムの監視やアラート、インシデント管理のプロセスを強化しているため、彼らのインシデントレスポンスのフローやドキュメンテーションの方法を理解することで、自社のインシデント管理の改善点を見つけることができます。

このようにして他社の成功事例や失敗事例を知ることで、自社のSRE組織立ち上げの際の方針や戦略をより具体的かつ効果的に構築することができます。

SREが目指す3つの指標

SREが目指す3つの指標について解説していきます。

サービスレベル目標（SLO）

サービスレベル目標（SLO）は、サービスの品質や性能を数値で示した目標値です。

サービスがどれだけの時間正常に動作するべきか、どれだけのダウンタイムが許容されるかなどを示す指標として設定されます。

Google Cloudなどでは、SLOはサービスの利用者やステークホルダーとの約束ではなく、内部的な目標として設定されることが多いようです。

例えば、99.9%のアップタイムを目指すというのがSLOとして設定されることがあります。

この目標を達成するために、SREチームは様々な取り組みを行い、サービスの品質を維持・向上させる努力をします。

サービスレベル契約（SLA）

サービスレベル契約（SLA）は、サービス提供者と顧客との間で合意された、サービスの品質や性能に関する公式な契約です。

SLAは法的な文書として形成され、SLOよりも厳格な基準が設定されることが多く、SLAが守られなかった場合、ペナルティが発生することもあります。

例えば、クラウドサービスの提供者が99.95%のアップタイムをSLAとして約束していた場合、それを下回った場合には補償が行われるなどが考えられます。

サービスレベル指標（SLI）

サービスレベル指標（SLI）は、サービスの現在の品質や性能を数値で示す指標です。

SLIはサービスの健全性を測定するための具体的な基準として使用されます。

例えば、リクエストの応答時間やエラーレートなどがSLIとして考慮されることがあり、SREチームはSLIを定期的に監視し、SLOやSLAと比較してサービスの健全性を評価します。

もしSLIがSLOやSLAの基準を下回っている場合、それはサービスに何らかの問題が発生している可能性が高いため、迅速な対応が求められます。

まとめ

いかがでしたでしょうか？

今回は日本企業における6つのSRE事例と4つの成功ポイントについて解説してきました。

SRE（Site Reliability Engineering）とは、元々Googleが提唱したシステム管理とサービス運用に対するアプローチで、その特長は、信頼性をシステムの重要な機能の1つと位置づけている点になります。

実際の日本企業の導入事例を知り、成功するための知恵を借りることは非常に重要です。

エンジニアに対しても・顧客に対しても信頼性の高いサービスを届けるために、環境を整えることは全ての企業でも心がけていきたいところです。

SNSシェア

• X
• facebook
• hatebu
• LINE
• pocket

CATEGORY

フリーランス

TAGS

SRE