• よくわかるクラウド
  • AWS
  • 運用
  • 障害

AWSを運用するためのベストプラクティス ~アプリケーションエンジニアの開発時間を確保するために~

デジタルトランスフォーメーション(DX)の必要性が叫ばれるなか、オンプレミス環境で構築されていたレガシーシステムをクラウド環境へ移行しようという動きが活発化している。そうした移行先のクラウド環境として、多くの企業に選ばれているのが「Amazon Web Services(以下、AWS)」だ。

もちろん、AWSへ移行したからといって、システムが正常に稼働し続けるわけではない。サービスの状態を常に監視しながら、年間1,000回以上の機能アップデートが行われるサービスの更新状況をキャッチアップし、継続的に“最適化”する必要がある。そのためAWSの運用は想像以上に負荷が高く、多くのエンジニアは十分な開発時間が確保できないという課題を抱えている。

そんな課題を解決するためには、AWSをどのように運用するのが望ましいだろうか。AWSの運用について、ベストプラクティスを考えてみよう。

システムの正常稼働を支える「運用」業務

オンプレミス環境・AWS環境を問わず、サービスが稼働するシステムの正常稼働を継続させるために欠かせない業務が「運用」だ。運用の業務内容には大きく分けて、システムの状態を監視して緊急時に対応する「障害対応」と、システムが安定稼働をし続けるように計画的に管理・準備する「定常運用作業」の2つがあるが、いずれの運用業務においても重要になるのが「最適化」することだ。

最適化と言っても、その内容は幅広く、例えば障害発生時の影響範囲を最小化するためにシステムの状態を適切に監視し、その監視データから障害発生を予測することも最適化に含まれる。障害から迅速に復旧できるようにシステム復元手順書を用意しておくなど、運用の業務内容を標準化することも最適化につながる。このように運用を最適化することの重要性は、オンプレミス環境もAWS環境も変わらない。ただし、取り組むべき内容には違いがある。

AWSの運用を最適化するための妥協点を探る

オンプレミス環境とAWS環境の運用には、どのような違いがあるのだろうか。最も大きく違うのは、運用に求められる責任範囲だ。

オンプレミス環境では、システム設置場所の空調からラック、電源、ネットワーク、ハードウェアまでの物理的な機器・設備の運用が欠かせない。そのうえで、OS、ハイパーバイザー、ランタイム、ミドルウェア、アプリケーションなどのソフトウェア部分も、運用の責任範囲となる。

それに対してAWS環境では、物理的な機器・設備の運用はクラウド事業者であるAWSが責任を持って担当する。企業が運用しなければならないのは、OSから上位のソフトウェアレイヤーだけだ。

ただし、物理的な運用を事業者に任せられるからといって、安心できるわけではない。実はAWSでも、システム障害はしばしば発生している。そこで必要になるのが、障害発生を考慮して運用を設計することだ。AWSでもシステム障害は起きてしまうものだと考え、障害の影響範囲を最小限にとどめたり、障害個所を切り分けて速やかに復旧させたりするための施策を講じるのだ。

もちろん、コストをかければ障害の影響範囲を最小化できるし、リソースを注ぎ込めば迅速な復旧も可能だ。しかしコストもリソースも無尽蔵ではないため、妥協点を探る必要がある。その妥協点もビジネスの変化に伴って変わってくるし、AWSの新機能が登場して選択肢が増えることもある。つまり妥協点を探って運用を最適化しても、それが永続するわけではない。言い換えると、運用を設計する際には、最初から「最適」を求める必要はなく、システム構成が変われば運用も変えて常に最適化し続けるというサイクルを回すのである。

このようにAWSの責任範囲も考慮しながら運用を最適化していくことは、簡単なことではない。そこでヒントになるのが、AWSが提供する「Well-Architected Framework」というドキュメントだ。ここにはAWSの運用におけるベストプラクティスが収められており、これを参考に運用を設計するとよいだろう。


 
(図1)AWSの責任共有モデル(出典:Amazon Web Services

AWS運用でのモニタリングとオペレーションの考慮点

本記事の続きはホワイトペーパーでのご提供となります。
下記のフォームからお申し込みをいただきますと、メールにてホワイトペーパーのURLをお送りします。

「AWSを運用するためのベストプラクティス」をダウンロード

おすすめの記事

おすすめのカテゴリ