AWSから見るインフラエンジニアの在り方

クラウドコンピューティング が一般名詞した現在においても、多くの企業はシステム運用を自社のデータセンター施設でサーバを稼働させ、運用を行う オンプレミス環境 下で展開しています。

クラウド環境ではなく、オンプレミス環境を利用する理由は企業によって様々ですが、オンプレミス環境で運用を行う上で避けられない様々な問題が存在し、改善したいと考えている企業も多いと思います。今回は Amazon Web Services (AWS) を利用して得られるメリットから、オンプレミス環境で発生する インフラ運用での問題点 について取り上げていきたいと思います。
 

オンプレミス環境で稼働するサーバやストレージ、ネットワーク機器を運用していく上で、必ず発生する問題が ハードウェアコンポーネントの故障 です。
コンポーネントの部位によって故障率は変動しますが、特に駆動部分が多い ハードディスク や 冷却ファン、消耗部材である バッテリー は稼働年数が経つほど交換が必要な機会が増えてくるでしょう。交換対応が増えるほど、インフラ運用において 人的リソース は増え、交換によって発生するリスク についても考慮する必要があります。加えて、ハードウェアのベンダーサポートは一定の期間をもって終了となります。ベンダサポートが受けられない老朽化したハードウェア機器はインフラ運用にとって脅威になります。

AWS環境 ではサーバ・ストレージ・ネットワークなどの、いわゆるハードウェア資源が クラウド上に存在 します。そもそもインフラ運用において、ハードウェアに関する運用設計を考える必要性はありません。インフラ運用者は空いたリソースを、他の対応に回すことができ、運用の効率化　を図ることができます。

システム運用を続けていくと、利用ユーザの増加や機能の追加等で、設計想定時よりもインフラリソースが足りなくなる ことはよくあります。そこでインフラリソースを増強する手段として挙げられる手法として 「スケールアウト」 と 「スケールアップ」 があります。

・スケールアウト
インフラリースが不足しているサーバ機器の集まりに対して、同じ構成のサーバを増やす ことにより、並列処理の能力を高める 方法。主にWebサーバや小さな処理を並列に処理するアプリケーションサーバ等の環境に適しています。

・スケールアップ
インフラリソースが不足しているサーバやストレージに対し、CPU、メモリ、Disk等を 増やしたり、より性能が高いものへ変更 する方法。主に一度の処理で多くのリソースを消費する環境に適しています。

オンプレミス環境ではスケールアウト、スケールインの対応についてどうしているでしょうか?

VMWare vSphere や Xen といった 仮想化基盤環境 においては、あらかじめリソース増強用のインフラリソースを用意しておき、柔軟にスケールアウトが実施できるようになっています。しかし、設計段階で 数年先のリソースの予測 が正確にできるでしょうか。リソース増強用のインフラリソースを準備していても、増強が不要だったケースも考えれます。その場合、準備していたインフラリソースのコストは無駄になってしまいます。

また、想定以上のインフラリソースが必要な場合やスケールアップが必要なサーバ機器の場合は、新たなハードウェアの購入 が必要になります。どの企業も新たなハードウェアを購入する場合は、必ず経営層の判断を要します。企業によって手続きの方法は異なりますが、その多くはリソース増強が必要と判断してからリソースが増強できるまで最低数ヶ月の期間が必要になります。プロジェクトの予算などで対応が次年度以降になることも少なくありません。
 

それでは AWS はどうでしょうか。

仮想サーバ 機能を提供する EC2 の例で見てみましょう。

まず、 スケールアウト は EC2 内のAutoScaling 機能 によって実現が可能です。
スケールアウトは、システムの開発・設計時 にサーバ数の増加を行うタイミングについて決定します。手動でスケールアウトを実施することも可能ですが、Auto Scaling を使用すると、基本的には EC2の CPU使用率 や上位にある ELB (AWSの負荷分散機能) のアクセス数 などを元に、スケールアウトに必要な条件を設定し、スケールアウトの条件に満たす状況となれば、新しいEC2インスタンスが自動的に起動 する仕組みになっています。

スケールアップ を行う場合も非常に簡単です。インスタンス（EC2 の仮想サーバ） の停止は必要になりますが、インタンスを停止後 に EC2の設定画面で2ステップでEC2 の インスタンスタイプの変更 が可能です。

オンプレミス環境のように 事前のハードウェアリソースの確保は不要 ですから、必要な時に必要なだけリソースが確保ができる のがAWSの魅力ではないでしょうか。

今回はインフラ基盤から見たAWSのメリットについて、以上の2点を取り上げましたが、AWSの魅力を伝えるにはほんの一部分に過ぎません。AWS で提供されるコンピュータインフラストラクチャサービス はストレージ、データベース、分析ツールなど既存のオンプレミス環境を補う様だけの種類が用意されています。
利用用途に応じて取捨選択が可能 なのもAWSの大きな魅力です。

AWSのように小規模サーバからハイ・パフォーマンス・コンピューティングまで広いニーズに対応したクラウドプラットフォームの他に、Oracle社 の OracleCloud や SAP社 の SAP HANA といったデータベース・ERP製品の基幹業務系サービス業界シェアトップに立っている企業が クラウド上でサービス提供 を行っています。

クラウド基盤はこれからさらに利用する機会が増えるでしょう。
その中で インフラエンジニア はどのようにあるべきなのでしょうか？

AWSをはじめとするクラウド基盤では基盤サービスを管理・操作を行うために 専用のAPI が用意されており、Ruby や Python といった 軽量型のプログラミング言語と親和性が高い ため、それらプログラミング言語やクラウド基盤で用意されているデプロイツールなどを使って、インフラ開発では サーバデプロイ処理、インフラ運用であれば定期的な メンテナンス や インシデント処理 の 自動化 を行うことが一つのトレンドになっています。

実際に 自動化 に関する処理を構築するために、開発・運用それぞれで別の担当者が自動化の仕組みを作るのはどうでしょうか。
極めて無駄のように見えます。近い将来、開発者と運用者の境はなくなる でしょう。いわゆる DevOps に対応できるエンジニア がこれから求められるインフラエンジニアの像でないでしょうか。

そのためには事前に必要なスキル・知識が必要になります。弊社IT教育メニューの中にこれからのインフラエンジニアに求められる技術に関するコースがいろいろ揃えておりますので、是非ご検討いただければと思います。

■Python入門
自動化で必要になってきている軽量プログラミング言語「Python」を学ぶことができます。
http://edu.jtp.co.jp/course/326

■Puppet Labs
自動化ツール「Puppet Labs」の管理方法をご紹介しています。
http://edu.jtp.co.jp/training/puppet_labs/index.html

■MapR
MapRクラスタの管理から、Pig, Hive, Drill, Spark など幅広く扱っています。
http://edu.jtp.co.jp/training/mapr/index.html

■Hortonworks
Hadoop ベンダHortonworks について、クラスタの管理方法ご紹介しています。
http://edu.jtp.co.jp/training/hortonworks/index.html