Production Readyと開発プロセス改善

SRE
このエントリーをはてなブックマークに追加 follow us in feedly

こんにちは。プラットフォーム技術戦略室SREチームの津田(@grim0h)です。 昨年の6月以来の投稿になります。

今回は、Cloud IoT OSに対して行なっているProduction Ready活動について紹介します。 ( この記事はInfra Study Meetup #3のLTで話した内容を詳細化したものです。LTの資料はこちらになります。)

Cloud IoT OS とは

Cloud IoT OS について簡単に紹介します。 Cloud IoT OS とは、あらゆる人に直感的なIoTデバイスの制御、データ解析、AI・クラウドサービス連携できるユーザ体験を提供するAI・IoTプラットフォームです。 マイクロサービスアーキテクチャで構成されており、コンテナ化された各サービスをKubernetesで管理しています。

www.optim.cloud

Production Ready とは

Production Readyとは、サービスを本番トラフィックに任せられるほどの信頼がある状態、その状態にするための考え方です。 もう少し噛み砕くと、各サービスが一定水準の信頼性を保ち、また、信頼性をコントロールできる状態にすることになります。
マイクロサービスエコシステムの場合を考えてみると、構成するマイクロサービスの1つでも一定水準の信頼性を満たしていない場合、マイクロサービスエコシステム全体の可用性に影響します。そのため、個々のマイクロサービスがアーキテクチャ/運用/組織をめぐる高い標準を満たす必要があります。 そこで必要になってくるのが、Production Readyの標準です。 これは以下の3つの対象と8つの原則からなっています。

  • 対象

    • システム、デリバリプロセス、運用

  • 原則

    • 安定性、信頼性、スケーラビリティ、対障害性、大惨事対応、パフォーマンス、監視、ドキュメント

これらの対象に対して、8つの原則についての一定水準の信頼性(基準)を定義したものがProduction Readyの標準になります。
サービスに対して、Production Readyの標準を導入するプラクティスとして、一般的によく見るものとしては以下のフローがあります。

  1. Production Readiness Reviewの実施

    • サービスに対して、Production Readyな状態であるか、Production Ready対応度合いをレビューします

  2. Production Readiness Checklistの導入

    • Production Readiness Reviewの結果をチェックリストに記載していきます
    • このチェックリストはProduction Readyに関する項目について記載してあり、各項目について一定の合格ラインを越えればProduction Readyなサービスであるといえます

  3. Production Readiness Roadmapの作成

    • チェックリストに記載した内容から足りていない部分に関して、今後のロードマップを引き、よりProduction Readyな状態にするために対応していきます

  4. SRE Onboarding/Takeoverの実施

    • 本番環境を管理しているチームにサービスを引き渡します
      • SREチームが本番環境を管理しているケースが多いため、SRE Onboarding/Takeoverとしています
    • 本番環境でサービスが稼働し続けるためにサービスの詳細な情報や障害時の対応方法などをSREチームに共有します

Production Readiness Cloud IoT OS

上記のProduction ReadyのプラクティスをCloud IoT OSに適用していきます。
Production Readyの導入モデルとしてはSRE本(『Site Reliability Engineering』(O'Reilly))32章「進化するSREのエンゲージメントモデル」に記載がある「早期エンゲージメントモデル」を採用しました。 なぜこの導入モデルを採用したのかというと、Cloud IoT OSに対するこれまでのProduction Ready活動において以下の課題があったためです。

  1. Production Readiness Reviewの課題

    • サービスをレビューするための情報に決まりがなく、サービスによって出てくる情報はバラバラだった
    • SREチーム内でレビューを行えるメンバーが限られており、属人化が起きていた

  2. Ops Onboarding/Takeoverの課題

    • ある時、新規サービスがリリース物に追加され、そのまま運用が始まる状態で引き渡しは行われていなかった
    • ( Cloud IoT OSはSREチームではなく、Opsチームが本番環境を管理しているため、Ops Onboarding/Takeoverとしています )

早期エンゲージメントモデル

「早期エンゲージメントモデル」とは、Production Ready活動の導入モデルの1つであり、早い段階から開発のライフサイクルにSREが関わっていくものです。
「設計」「構築/実装」「ローンチ」「ローンチ後」という開発プロセスの各フェーズにSREが関わり、「設計」時にはProduction Readiness Reviewの実施、Review結果をProduction Readiness Checklistに反映を行い、「構築/実装」「ローンチ」時には設計したものを実現させるために構築/実装、ローンチ支援を行います。また、「ローンチ後」には、SRE Onboarding/Takeoverを行い、継続的改善のためにProduction Readiness Roadmapを作成します。

https://cdn-ak.f.st-hatena.com/images/fotolife/o/optim-tech/20200630/20200630145925.png

この導入モデルを採用することで、上記の課題の解決を開発プロセスに根付いた形で行うことができます。

早期エンゲージメントモデル type Cloud IoT OS

「早期エンゲージメントモデル」をそのまま導入することはできない、且つ他の目的も達成したいという思いから、「早期エンゲージメントモデル」をベースに導入モデルを再定義しました。
「他の目的」というのは、レビュー対象としてのドキュメント作成とドキュメントテンプレートの作成です。このドキュメントを各サービスで作成し、メンテナンスしていくことで常にProduction Readyの対応状況、対応に対する裏付けが参照できる状態になります。

https://cdn-ak.f.st-hatena.com/images/fotolife/o/optim-tech/20200630/20200630145919.png

この導入モデルでは、「企画」「設計」「開発」「運用」という開発プロセスの各フェーズにSREが関わります。
「企画」時には、非機能要件に対して、SLA/SLOやセキュリティ要件、想定負荷などについて、定義されているか、実現性、妥当性があるかレビューしていきます。「設計」時にはProduction Readyの観点でDesign Docというドキュメントを作成していただき、Design Docのレビューをしていきます。(Production Readiness Reviewに該当します。)「開発」時には設計したものを実現させるために支援を行います。また、「開発」の最後に運用引き渡しを行いますが、それに伴ってDeployment Instruction, Runbookというドキュメントを作成していただき、インフラ/運用チームがそれをレビューし、運用フェースに移行します。
(SRE Onboarding/Takeoverに該当します。但し、Cloud IoT OSはSREチームが本番環境を管理しているわけではなく、運用チームが管理しているため、正しくはOps Onboarding/Takeoverとなります。)

「早期エンゲージモデル」との差分

「早期エンゲージモデル」、従来の一般的なProduction Readyのプラクティスとの差分としては、以下2点の追加になっています。

  1. Planning/Infra/Ops Entrance Review

  2. Service Docs

Planning/Infra/Ops Entrance Review

企画フェーズから運用開始までの全てのフェーズで非機能要件についてレビューしていくのですが、SRE Onboarding/Takeover と Ops Onboarding/Takeoverの違いのように実際にインフラ構築、運用をしていくのはインフラ/運用チームであったりするため、SREチーム以外の関係するチームにもSREチームと同じタイミングでレビューを行なっていただきます。

Service Docs

「Service Docs」というのは「早期エンゲージメントモデル type Cloud IoT OS」 時に作成していたドキュメントの総称です。
現在は以下の4つのドキュメントを含んでおり、テンプレートを用意しています。

  • Design Doc
  • Runbook
  • Deployment Instruction
  • Load Test Report
Design Doc
  • 設計書
  • Production Readiness Checklistに含まれる項目をドキュメントで表したもの

  • 実際の項目

    https://cdn-ak.f.st-hatena.com/images/fotolife/o/optim-tech/20200629/20200629104515.png

Runbook
  • 運用手順書
  • 運用者がサービスを運用するにあたって、障害対応方法や監視方法などを記載するドキュメント
  • このドキュメントを参照すれば運用できる状態になることが求められる

  • 実際の項目

    https://cdn-ak.f.st-hatena.com/images/fotolife/o/optim-tech/20200629/20200629104521.png

Deployment Instruction
  • システム構築基礎知識
  • システムを構築するにあたって、構築方法やサービスのデプロイ方法を記載するドキュメント
Load Test Report
  • 負荷試験実施レポート
  • 負荷試験の実施方法、結果などSREや他開発者が分析しやすいように必要な情報を記載するドキュメント

今後の対応

今回、「早期エンゲージメントモデル」をベースとした導入モデルを採用し、Cloud IoT OSに対するこれまでのProduction Ready活動においての課題を解決することができました。しかし、Production Readyのプラクティスにある、Production Readiness ChecklistやProduction Readiness Roadmapが足りていない状態です。また、Production Readyの導入モデルを各サービスに導入していくのは良い活動ですが、Cloud IoT OSはマイクロサービスアーキテクチャを採用しているマイクロサービスエコシステムであり、SREチームはCloud IoT OS以外のサービスにも働きかけようとしている状態であるため、常にサービスの数に見合ったリソースが確保できない状態にあります。そのため、Production Readyの導入モデルを導入しなくても各サービスがProduction Readyな状態になるような活動もしていかなければなりません。 以下に現在検討している対応を記載します。

  • Production Readiness Checklist の本導入

    • Production Readiness Checklistは作成しているが、レビューの観点が記載されているドキュメントという扱い以上のことが行えていない
    • Production Readiness Review時にドキュメントのレビューとは別にチェックリストに対応状況を記載していく
      • Production Ready 対応状況を一目でわかる状態にするため

  • Production Readiness Roadmap の導入

    • 継続的な改善のためにチェックリストの結果からロードマップを作成する

  • Guideline の拡充

    • 記載内容に則ればProduction Readyになるようなガイドラインの提供

  • Production Ready なコード、設定の提供

    • Production Readyにするためのベストプラクティスを設定できるようなライブラリや再利用可能な共通設定などの提供

さいごに

現在、Cloud IoT OSで行なっているProduction Readyについて紹介しました。
今回紹介した導入モデルは、SRE本(『Site Reliability Engineering』(O'Reilly))に記載があった方法をそのまま使用したのではなく、Cloud IoT OSに適用させるために再構築したものになります。このように、Production Readyのアプローチはサービス/チーム特性によって異なるものであるため、皆さんのサービスに適用するにはどのような方法を取れば良いか考える必要はありますが、是非導入してみてください。
Cloud IoT OS、SRE、Production Readyに興味があると言う方は是非一度オプティムを訪れてみてください。

www.optim.co.jp