【重障害回避】サービスレベルが高いシステムの構築のポイントは？

システムの構築にあたっては、サービスレベルの意識が重要です。運用するシステムの内容によって、レベルは変化するものの、一般的にはサービスレベルが高いに越したことはありません。事前に定められた品質を担保するために計画的なサービスレベルの向上が求められます。

エンジニアとしてサービス全てが重要だと認識できている人が多いですが、具体的に向上させる手法まで理解できているケースは限られています。様々な場面でシステムのサービスレベルは求められるため、どのように向上させていくか解説します。

システムのサービスレベルとは

システム運用におけるサービスレベルとは、システムやITサービスの品質やパフォーマンスを示す指標です。一般的にサービスレベルは、サービスの提供者と利用者の間で事前に合意されるものです。そのため、サービスレベルが高いかどうかは、合意した内容によって左右されます。絶対的な指標ではなく、事前に合意された内容を基準にした相対的な考え方だと理解しましょう。

サービスレベルを理解するに当たっては、サービスレベルアグリーメント（SLA）の理解が必要です。SLAはサービスの提供者と利用者との間で締結される合意書です。一般的には以下のような内容が含まれます。

• サービスの範囲：提供されるサービスの詳細と範囲
• パフォーマンス指標：サービスの品質を測定するための指標（例：稼働率、応答時間、解決時間）
• 報告とレビュー：サービスレベルの達成状況を定期的に報告・レビューする方法
• 補償：サービスレベルが達成されなかった場合の補償

これらは一例ですが、SLAには事前に定めておかなければトラブルが生じやすい内容を記載しておくと考えましょう。そして、サービスレベルが高いかどうかは、ここで定義された内容を踏まえて判断を下すという流れです。

システムのサービスレベルを定める目的

サービスレベルを定めておく目的は、サービスの提供側と利用側で事前に共通の認識を持つためです。また、共通の認識を持った状態で、サービスを提供することも目的に含まれています。提供側は常にサービスレベルを満たせるように努力する義務があるのです。

サービスレベルを定めておくことで、サービスの提供側も利用側も、トラブルの発生時に行動しやすくなります。また、責任の所在が明らかになりやすいなどの効果もあるのです。いち早くトラブルを解決し顧客満足度を高めるために、サービスレベルを定めると表現しても差し支えないないでしょう。

サービスレベルに関与する指標

続いては、システムのサービスレベルを考えるにあたって、どのような指標が利用されるか紹介します。

可用性

システムやサービスが利用可能な時間の割合を示したものです。例えば、このシステムの可用性は99.9%と定義します。この場合であれば、1年間において約8.76時間のダウンタイムを許容できるということで合意しているのです。これよりダウンタイムが短ければ、可用性が高いと言えます。

応答時間

ユーザーがリクエストを送信してから最初のレスポンスを受け取るまでの時間です。応答時間はユーザーの利便性や、システムやサービスに対する印象を大きく左右します。そのためサービスレベルの中でも重要視されやすい項目です。全体についての応答速度が定められることもあれば、通常の画面表示や検索結果の表示、データの送信など機能ごとに細かく定められることもあります。

回復時間

システムに障害が発生した際に、通常の運用状態へと回復させるまでの時間です。回復時間が短ければ短いほど、ユーザーに対する影響を最小限に抑えられます。そのため、可能な限り短い時間に設定することが一般的です。ただ、回復時間を短くするとコストが高まりやすいなどの問題があります。そのため、実際にはコストと効率の両面から評価しなければなりません。

エスカレーションのプロセス

トラブルが発生した際に、どのようなフローでエスカレーションするかは重要です。エスカレーションとはトラブルの内容を上位の担当者に引き継ぐ作業を指します。例えば、データセンターの担当者がトラブルを検知して上長に報告し、そこからシステムオーナーに連絡するなどです。基本的な流れはもちろん、連絡がつかなかった場合は誰が代理であるかなども決定しておきます。

キャパシティプランニング

必ず含まれるわけではありませんが、将来的な需要を見越してシステムリソースを計画したり、調節したりすることがあります。例えば、従業員の増加を見越して翌年度にCPUやメモリを増強することを計画しておくのです。定期的にストレージを増加させることもあるでしょう。これらの作業は状況に応じてその都度対応することも多くあります。しかし、それでは遅れが生じてしまうことが多いため、事前に計画しておき、安定化を目指すのです。

システム運用におけるサービスレベルの具体例

サービスレベルを定義する際には「サービスレベルアグリーメント」が必要であると解説しました。実施に合意する際には、以下のような事項を定義しておきます。

• サーバー可用性：99%以上
• バックアップ取得数：1日1回以上
• バックアップの保存時間：7日間
• 障害検知の平均時間：5分以内
• 障害のワークアラウンド対応時間：10分以内
• 作業ミスの件数：1年に5回以内
• 障害復旧時間：12時間以内
• サービス提供開始時間遵守率：99%
• レスポンス平均速度：3秒以内
• ネットワーク稼働率：99%

なお、これはシステム運用におけるサービスレベルアグリーメントであるため、アプリケーションやインフラに関する項目が中心です。ただ、実際にはヘルプデスクなど問い合わせに対応するという観点でのサービスレベルアグリーメントもあります。これらについては観点が異なるため、ここでの説明は割愛しますが、目的に応じた事項を定義することが重要です。

サービスレベルの高いシステムの設計方法

上記の内容を踏まえてどのような設計にすればサービスレベルが高まるか考えていきます。

信頼性

冗長性の確保と障害対応は、サービスレベルの高いシステムに必須です。万が一に備えた仕組みを整えなければなりません。

まず、冗長性の確保では、ハードウェアとソフトウェアの両面から考慮する必要があります。例えば、ハードウェアの信頼性を高めるためには、サーバーやネットワーク機器の冗長化を実現すべきです。RAID構成によるディスクアレイ、デュアルパワーサプライなどが考えられます。また、ソフトウェアで信頼性を確保するためには、クラスタリングやレプリケーションを活用して、障害時に備える設計が必要となるでしょう。

続いて、障害に対応するためには、リアルタイムに監視したり異常を検知したりする仕組みが必要です。また、検知した内容を即時にアラートで知らせる仕組みも構築しなければなりません。サービスレベルを高めるためには、いち早い検知と対応が重要であるため、これを実現できるようにするのです。他にも、故障した際に自動的に代替システムに切り替わるような仕組みも必要です。

パフォーマンス

サービスレベルを考慮する際には、パフォーマンスを高めなければなりません。例えば、応答速度を意識して、利用しやすい環境を提供することが重要です。頻繁にアクセスされるデータをキャッシュに保存することで、応答時間を短縮し、高速でデータを提供する方法があるでしょう。また、データベース設計によって、クエリの実行速度を最適化するなども考えられます。

ただ、パフォーマンスの確保はサービスレベルで考慮すべき事項ですが、システム的な部分については後から変更できるものではありません。例えば、サービスレベルが下がってきたからといって、短時間でキャッシュを活用したアプリケーションに改修することは難しいでしょう。新しく開発する際に考慮できれば理想的ですが、既に開発が完了しているシステムでは限界がある部分です。

他にも、パフォーマンスを高めるために負荷分散を採用する選択肢があります。例えば、ロードバランサーを導入して、リクエストを複数のサーバーに均等に分散するなどです。物理的なロードバランサーやソフトウェアベースのソリューションは、後からでもサービスレベルを高めるために採用できます。

可用性

可用性の高さは、サービスレベルの設計において重要視されやすい部分です。利用者の利便性を大きく左右する部分であるため、コストが許す範囲で可用性を高める設計を採用します。

まず、事前に求められた稼働時間を守れるような設計にすることが求められます。例えば、24時間365日稼働が求められるならば、システムを無停止で運用できる仕組みを設計すべきです。無停止でメンテナンスできる仕組みを考えたり、障害に備えて複数のサーバーから構成するなどが挙げられます。

また、可用性を高めるために自動化を活用した設計も必要となるでしょう。例えば、障害が発生した際は自動的に検知してスタンバイしているサーバーへ切り替えるなどです。近年は、さまざまな作業が自動化されているため、サービスレベルの向上に役立つものがあれば採用することをおすすめします。

スケーラビリティ

中長期的なサービスレベルの高さを考慮するならば、スケーラビリティも視野に入れることをおすすめします。特に、拡張性の高さとリソース管理は注目しておきたい観点です。

まず、利用者の増加に備えて、スケーラビリティを考慮した設計を採用します。例えば、クラウドサービスを利用して、必要ならばリソースを追加できる仕組みを整えておくのです。また、リソースを追加する手順なども整えておきます。他にも、コンテナ技術を活用して、アプリケーションのデプロイやスケーリングを素早く実施できるような仕組みもおすすめです。

加えて、リソースを動的に割り当てられる仕組みも理想的です。例えば、アクセス数が増えた場合のみ、メモリの割り当てを増やして処理を高速化することが考えられます。サービスレベルの基準を守りつつ、コストも高くなりすぎない仕組みには「動的な割り当て」が非常に重要です。

作業品質

アプリケーションやインフラなどテクノロジーに関する部分だけではなく、担当者の作業品質に関する部分も定義すべきです。これが定められていないと、サービスレベルが高いかどうか評価できなくなってしまいます。

例えば、障害の発生を感知して、関係者に展開するまでの時間を定めておくべきです。時間に余裕があるかどうかで、どのような仕組みを構築すればよいかが変化します。また、運用に携わるエンジニアの人数などにも影響するでしょう。

また、トラブルを検知するだけではなく、検知した後の対応速度についても定義すべきです。例えば、障害を検知してから解消までの時間は、できるだけ短いほうが良いでしょう。この時間を長く設定すると、トラブルの解決が後回しにされてしまう可能性があります。

とはいえ、一般的に作業品質を向上させると、どうしてもコストが高くなりがちです。多くの要望があるかもしれませんが、コストとの兼ね合いは考慮するようにしましょう。

まとめ

システム運用におけるサービスレベルの意味合いと、これを高める方法について解説しました。状況に応じて「サービスレベル」の意味合いは変化するため、まずはシステム運用で求められる内容を理解することが大切です。

実際にサービスレベルを設定する際は、解説した観点から多角的に設定する必要があります。ただ、サービスレベルの向上にこだわりすぎると、莫大な運用コストが生じることになりかねません。システムの重要度合いなどを踏まえて、費用対効果を考えることも重要です。