SLA

🐾 猫で例えると？

机のそばで、2匹が並んでこちらを見ています。まるで厳しい先生のようですね。もし「毎日19時から30分間、勉強を見守る」と利用する側と見守り役が合意し、守れなかったときの対応まで決めたなら、その取り決めがSLAに対応します。見張る動作そのものではなく、何をどの条件で提供すると約束したかがポイントです。

💻 IT現場における「SLA」とは？

AWSやGCPなどのクラウドサービスを利用する際、インフラエンジニアが必ず確認するのがこのSLAです。「月間稼働率99.9%を保証する」といった形で、サービスがどれだけの時間、正常に動き続けるかを数値化して約束します。

稼働率は、月間か年間か、どの構成が対象かで意味が変わります。例えば30日間をすべて測定対象にした99.9%は停止43.2分に相当しますが、実際のSLAでは停止の定義や除外条件が定められています。年単位へそのまま置き換えず、文書の計算方法を読みます。

⚠️ SLAの仕組みと注意点

未達時の対応は合意内容によります。クラウドサービスでは、現金の返金ではなく将来の料金に充てるサービスクレジットで、申請期限や必要な証拠がある場合もあります。損害の補償範囲も契約ごとに確認し、「稼働率の約束があるから停止しない」とは考えないことが重要です。

💡 SLA、SLO、SLIの使い分け

現場では、SLAを守るための内部指標として「SLO」と「SLI」をセットで運用します。

説明用の、同じ測定条件にそろえた例
SLI：対象リクエストのうち、正常に完了した割合
SLO：その割合を月間99.95%以上に保つという運用目標
SLA：顧客と合意する基準、測定方法、未達時の扱い
※実際のSLAは時間や構成など別の条件で測る場合もある

SLOはSLAがないサービスでも設定できます。SLAより余裕を持つ目標は有用ですが、測定対象や計算式が違う数字を大小だけで比べないようにします。

🛠️ SLAを賢く使うためのポイント

クラウドや外部APIを導入する際、SLAの観点からシステムを堅牢に保つための注意点です。

• 対象の構成と除外条件を確認する：基盤のSLAが、そのままアプリ全体の可用性になるわけではありません。自分たちの設定や外部依存、責任範囲も合わせて確認します。
• 必要な復旧水準から構成を選ぶ：複数拠点は選択肢の一つですが、費用と運用の複雑さが増えます。SLAだけでなく、復旧時間とデータ損失の目標から判断します。
• 監視とアラートの自動化： SLIがSLOを下回りそうになった（エラーバジェットが枯渇しそうになった）時点で、運用チームに即座に通知が飛ぶ仕組みを構築する。

勉強を見守る約束を時間まで決めるように、SLAでは品質を測る条件を具体化します。稼働率の数字だけでなく、対象の構成、除外される停止、未達時の申請条件まで確認しましょう。SLAの補償と、自分のサービスを何時間以内に復旧させたいかは別に考える必要があります。