RASISとFour Keysについて今一度向き合ってみる
どもども、最近めっきり冷え込んできましたね。春よ、来い。
インフラエンジニア、あるいはSREエンジニアとして日々情報収集を行う中で、特に勉強会などで聞く単語があります。それが、RASISとFour Keysです。
私自身、どうやら何かしらの指標であるというざっくりとした認識止まりであり当然これらを生かした運用はできておりませんでした。
聞いたことがあるで終わってしまうのは非常に勿体無いので、これらについて今一度向き合ってみようと思います。
RASISとは何か
IT用語辞典を見てみると以下の単語群の頭文字をとった略称であることがわかります。
- Reliability(信頼性)
- Availability(可用性)
- Serviceability(保守性)
- Integrity(保全性)
- Security(機密性)
こうしてみてみると、SREよりはインフラ寄りの指標というのが個人的な感想です。(もちろんアプリケーション開発の指標としても有用だと思います)。
これからインフラを作成する、または再構築するフェーズの組織にとっては非常に便利な使用ですね。
また、これまで運用してきたインフラ構成の見直し基準として利用してもいいでしょう。
ここでそれぞれの特性についてみてみましょう。
Reliability(信頼性)は不具合や障害による性能問題をどれ程抑えられるかという観点です。スペックは適切か、ミドルウェアチューニングは行われているかなどインフラ性能そのものを注視しています。
Availability(可用性)は稼働率の高さ、つまり停止時間の短さです。いくら信頼性に投資してもサーバーは予期せぬ障害を発生するものです。大切なのはその障害をどれほど許容できる構成になっているかということです。冗長化がその代表たるものになるでしょう。部分的な障害に対しては稼働を止めることなく運用が続けられる構築を考えることが大切です。
Serviceability(保守性)は運用性の高さです。復旧、メンテナンスについてどれほど整った体制が取れているかがポイントになります。復旧手順はしっかり整備されているか、復旧体制は整えられているか、あるいは復旧はなるべく自動化されているかなどを確認しておくのがよさそうです。またメンテナンス手順はシンプルにまとまっているか、メンテナンス項目はなるべく決まったものになっているか、メンテナンス対応できる人員は複数人確保できているかといったところも確認しておかなければいけません。
Integrity(保全性)はデータの一貫性です。負荷や障害、操作によるデータの損失、不整合、改ざんをどこまで起きないように設計しているかが大切です。web、アプリケーションサーバとDBサーバは切り離しておき、DBのバックアップはなるべく高頻度で取得しておくなど対策を心がけておきましょう。
Security(機密性)とは安全性です。外部からの攻撃や不本意な接続、破壊行動を未然に防ぐことができる構成になっているかを考えます。保守性と部分的に被るかもしれませんが、攻撃があった際にどれだけ早く察知、対処できるようにしているかも意識しておきたいですね。
さて、こうしてみると非常に基本的な指標であることがわかりますが、問題はこの指標をどのように利用するかだと思います。
開発者自身が体に刷り込むように常日頃から意識するのもいいと思いますが、折角綺麗にまとまったものなのでシステマチックに利用するのがよさそうです。
例えばPRコメントに自動で記載されるようにし、レビューする側も意識できるようにしておくといった利用方法が考えられそうです。
開発部門全体の共通認識とすることを目指していきたいですね。
Four Keysとは何か
ここまでRASISについて確認してきましたが、ではFour Keysとはなんでしょうか。
DevOps Research and Assessment（DORA）が示す指標は以下の4つです。
- デプロイの頻度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
Four keysがRASISと異なる点としては、パフォーマンスを重視して信頼性を向上するための指標になっているということです。
デプロイの頻度は本番環境に対し正常にどれくらいの頻度でデプロイできているかを測ります。本番環境にデプロイするたび変更箇所でエラーが発生すると、その都度サービスへの信頼性は低下していきます。検証環境を充実させることや明確なデプロイフローの確立、CI/CDの改善などによる正常なデプロイの頻度を上げることが求められそうです。
変更のリードタイムは変更箇所の発生から実際に本番環境に適用されるまでの時間を測ります。この時間が短ければ短いほど非常に早いスパンで機能がどんどん改善されるのでサービス信頼性は向上します。また、デプロイの頻度の向上にもつながるのでこれら2つは非常に関係が深いことがわかりますね。
変更障害率はデプロイが原因で発生する障害率です。こちらもデプロイの頻度と結びつくものですが、新機能がリリースされるたびに問題が発生していては信頼性が低下します。デプロイフローや動作環境手順の見直しなど数値に問題がある場合は抜本的な改革が必要になります。
サービス復元時間は本番環境での障害復旧時間を計測します。RASISでは障害に対してどのような対策がとられているかという視点だったのに対し、Four Keysでは障害発生点から復旧点までの時間を確認しています。障害復旧体制が整えられていたとして、結局障害復旧まで時間がかかるものだった場合問題となります。復旧時間を計測し今用意している体制は果たして正しいのかという判断基準にするのがよさそうですね。
Four KeysはRASISと違い計測確認するのがそもそも難しそうです。自前で管理する仕組みを作成するよりはFour Keys パイプラインやDatadog DORA Metricsなどを利用して計測するのがよさそうです。
まとめ
今回はRASISとFour Keysについてまとめてみました。
個人的にはRASISの徹底から初めて、Four Keysの計測につなげていくのがよさそうに思います。Four Keysは導入ハードルが少し高めですね…。
アプリケーションやインフラの構成レビューなどに対し、何をもっとよしとするか曖昧になっている組織には一つの参考になりそうです。
Four Keysについてはいろんな企業様の導入事例を拝見したいですね！
それではまた。