こんにちは。サービスデスクチームの中村(哲)です。
今回は、 Amazon Web Services(以下、AWS)を利用する際にITIL観点での注意点をお話しようと思います。今後、AWSとITILを導入する上での参考になれば幸いです。
もともと、業務で使っているAWSですが、技術面ばかりに注目してしまい気づいたらITサービスマネジメントとしての観点をないがしろにしていたので、ITILベースのサービスマネジメントで管理するにはどうするのがベストかを検討しておりました。
※ITILは、もともと運用のものだろ。っと、思っている方は以下のサイトに目を通してみて下さい。
ITILって？　?5つのコアプロセス?
まず、AWSを利用する上での分かりやすいメリットとしては、
・初期費用なし
・短期間でのインフラ調達・準備
・柔軟なスペック変更
・物理的な制限なし
など、今までならば機器調達する際は、用途とスペックを考えた機器選定、設置場所の確保、稟議を通したりして準備に数週間から１ヶ月程度掛かっていましたが、AWSを使えば数分で使用可能になる上にスペック変更もあとで調整できるのでインフラ準備が段違いに早くなります。
(自前調達ですと他の部署からのお下がり使うしかないときもありますが。。。)
 

検証ひとつするにも、今までの環境ならばOSの入れ替えだけでも数時間かかっていたのが、AWSなら数分で検証に必要な台数を同じ構成で準備が出来る。もう、コンパクトディスクの入れ替えとかをやらなくていい。怒られながら作ったキックスタートやゴールデンイメージの構成が間違っているから、やり直しで数時間。などからの開放。とても快適です。
快適なんですが、私がサービスマネジメント観点でAWSを見つめなおした際に思ったのは、作業観点の快適さばかりに注目してよいのか？
瞬間的に用意できるくらいに早くなったインフラ調達が不都合な真実を生み出していないのか？ということです。
車で例えるならエンジンがものすごく性能が上がったが、他の部品はそのエンジン性能に追いつかない限り車としての性能（価値）が上がらないばかりか、逆にそのことにより弊害が出るのではないかということです。
●そこでITIL


ITILでは、「有用性」と「保証」を兼ね備えたものを「価値」と定義しており、この観点で考えればAWSは上記の図の一例のように「物理的制約の排除」、世界中にあるリージョンによる可用性と豊富なマシン資源、第三者認証取得などにより「有用性」と「保証」を兼ね備え十分「価値」はありますが、ITILとしてのAWS使用者側の観点で以下に注意点を書きます。
１．AWSの機能がサービスの戦略目標に即しているかを判断する
AWSを使うことによって、構築や開発観点としてはサクサク作業が進むのでとても快適ですが、ITILとしての考え方は『サービスを通して顧客に価値を提供する』と謳っており大事なのはAWSを使うことによってどういう価値が提供出来るのかを定義し自社の戦略に有効か判断することです。
例えば、「顧客ニーズに早く対応するためにサービスリリースを早くする」という戦略に対して、AWSを導入しインフラ構築を改善しても、運用体制やソフトウェア調達、社内承認などの準備が今までのインフラ構築よりも時間がかかっている場合は、結果としてサービスを今までより早くリリースすることは出来ません。つまり、部分的な改善は全体的な観点で見ると効果が無い場合もあります。
２．ITILはサービス全体で設計を行い品質管理する
AWSでは、システムのスケールアップ、スケールアウトが容易に出来るようになったが、それは今まで実施していた設計がいらなくなったわけではありません。
むしろ、スケールアップ、スケールアウトによる対応だけでは、リアクティブな対応の観点が高く、そのような状況が続けば場当たり的な設定変更が多くなるため技術的負債を抱え込む可能性が高くなります。
AWSで動かすシステムの可用性やキャパシティはもちろんですが、人、プロセス、パートナーなどのサービス提供全体としての観点で設計を行う必要があります。
３．乱立したシステムは、開発環境、本番環境問わず柔軟性を低下させる
私が一番大きい問題と感じるのがこの問題です。
冒頭でも書いたように、AWSはスピーディで柔軟性の高い便利なサービスです。
その便利さが今まで以上にシステムが立ち上がるスピードを上げます。
各部門、各部署、プロジェクトが使いやすいようにカスタマイズした個別のシステムが物理システムよりも早いスピードで増加していく一方で、物理サーバの購入のように納入・設置等の視覚的な確認が無い中でシステムが追加されるため、新しく出来たシステムがより把握しにくい状況が容易に生まれます。
以前、私が関わった物理システムからクラウドへの移行プロジェクトでは、システムの一元管理を行うため運用設計の前段階として各部門、各部署が個別に構築した以下の状況を把握するだけでも数ヶ月の時間を費やしました。
・システムの構成情報
・誰が使用しているか？
・どの業務に使用しているか？
・メンテナンス･保守をするノウハウがあるか？または、運用で引き継げるか？
上記の情報がなければ、変更をコントロールするための工数が大きくなり、変更の失敗・切り戻しのリスクも高くなるため結果ビジネススピードが遅くなります。
AWSでの場合、既存のセキュリティグループを管理者が把握してないシステムで使用すると、ポリシー変更を行った際に思わぬところで影響が出ることもあるかと思います。
また、AWSのような従量課金は、起動台数 × 起動時間という形で課金が発生するので塩漬けになって使用してないシステムも同様のコストが発生するため、上記の把握はより重要になります。
 
●まとめ
このように、AWSを導入することによりメリットと思われていることが利用者側の管理方法によってデメリットになる可能性があることを認識し、無法地帯にならないようにAWSをコントロール出来る状況下に置くことがAWSを効果的に使い始める一歩であると考えます。
今回書きました注意点は通常の業務で考慮しているからITILじゃなくても問題ないという声もよく聞きますが、明示的に管理ルールを文章化されている事が少ないのが現状です。他にもITILを導入しても時間がかかる上に定着しないので効果がないという声も多く聞きます。
しかしながら、私としてはAWSのように変更が多く幅の広いサービスを使う上では、AWSをコントロールしながらITILのプロセスを段階的に導入することにより、早い段階でITILとAWSの相乗効果が得られると考えます。
特に需要管理、構成管理、変更管理などは、AWSと親和性が高いプロセスと感じております。
ただ、ここまで書いておりますが実際使ってみないとAWSのメリットを実感したり、コントロール方法を習得するのは、正直難しいと思います。
―――――――――――ここからは、宣伝になります――――――――――
それならば、AWSの使用を少し制限された環境で導入を行い徐々に現在の管理とAWSを平行して利用していくのが安全です。
弊社サービスの「ECO Pack」では、初期構築は基本構成を選ぶだけで自動的にプロビジョニングされるサービスとなっており、拡張性を考慮した設計で基本的には月額制のサービスのため安心してご利用いただけますので、是非ご検討してみて下さい。
●ECO Pack