AWS Instance Schedulerに代わる、N2WSリソースコントロール機能を使用して、簡単ワークロード管理 [N2WS Backup & Recovery]


オンデマンドのインフラストラクチャが誰にでも実現可能なものとなった今日、AWSは、あらゆるタイプのワークロードを迅速かつ容易に実行できる機能性を特長としています。費用も使った分だけ支払うPay-As-You-Go方式なので、資本支出が抑えられ、大きな利益がもたらされます。運用コストだけ用意すればよいので、特に小規模の新興企業などにとっては大いに役立つところです。しかし、ほとんど無限のリソースにすばやくアクセスできる状況はオーバープロビジョニングにつながります。EC2(Elastic Compute Cloud)インスタンスならなおのことです。

その上、支払いは稼働しているリソースに対して発生し、それが実際に活用されているかどうかは関係ないので、待機状態のインスタンスを余計に配備すれば、不必要に経費がかさむことになります。つまり、使用されていないリソースを停止させれば、それだけでインフラの大きな節約となるのです。そして、それがまさにAmazonが昨年初頭にInstance Schedulerという新サービスの提供を開始した理由です。

本稿では、AWS Instance Schedulerを考察し、その利点と欠点を検証します。また、Instance Schedulerの代替ツールともなるN2WS Backup & Recoveryについても検討していきます。

AWS Instance Scheduler

AWS Instance Schedulerは、EC2(Elastic Compute Cloud)インタンスとRDS(Relational Database Service)インスタンスの自動的な起動と停止をニーズに合わせてコンフィギュレーションできるAWSソリューションです。このInstance Schedulerは、いくつかの異なるサービスの組み合わせで構成されています。まず、CloudWatchがLambdaファンクションを呼び出し、そのファンクションがインスタンスを開始または停止させます。すべてはCloudWatchに登録され、DynamoDBにコンフィギュレーションが保存されます。全体的な構成はCloudFormationテンプレートによってプロビジョニングされ、それを図解すると以下のようになります。


CloudFormationスタックのプロビジョニングにおいては、スケジューラにこまごまとした定義が必要になります。まず、AWSアカウントと使用するリージョンをセットアップした後、カスタムタグを作成し、それによってEC2インスタンスとRDSインスタンスを定義できるようにしなければなりません。ここで指定するタグの値は、適用すべきスケジュールを識別するのに使われます。タグは個々のインスタンスに、後から自分で追加しなければなりません。最後に、CloudWatchイベントのカスタムインターバルを設定する必要があります。それにより、Instance SchedulerのLambdaファンクションが起動されます。

すべてのコンフィギュレーションはDynamoDBテーブルに保存され、各Lambdaファンクション実行時に読み込まれます。ファンクションが起動されると、タグに一致するリソースの稼働状態が確認され、あらかじめ定義されたスケジュールのコンフィギュレーションテーブルにもとづき、既定の稼働状態と異なっていたら、それと一致するようにインスタンスが起動または停止されます。

スケジュールのコンフィギュレーションでは、1つ以上のperiod(開始から停止まで)を設定し、任意でタイムゾーンを指定します。また、インスタンスタイプも選択でき、設定されたスケジュールが特定のグループのインスタンスにだけ適用されるように指定することができます。その他のオプションとしては、定義されたスケジュール外に手動でインスタンスの起動と停止が行われないように強制するenforcedフィールドがあります。値がtrueに設定されたら、タグ付けされたインスタンスはスケジュール外に手動で起動しても、スケジューラがただちにそれを停止します。同様に、手動で停止しても、本来稼働すべきスケジュールであれば、スケジューラがただちにそれを起動します。コンフィギュレーションで選択可能な各種オプションの完全リストはAWSの資料を参照してください。

AWS Instance Schedulerの利点と欠点

AWS Instance Schedulerは、インスタンスが常に稼働し続けてしまうのを防ぐのに有効な解決策となります。特に、コンピューティングリソースを常時フル活用していないユーザーにとっては、月々の支払いが大幅に削減されるでしょう。また、Instance Schedulerは複数のAWSアカウントとともに使用でき、スケジュールのコンフィギュレーションにコマンドラインインタフェース(CLI)を使用できる点も便利です。

Instance Schedulerは、前述の通り、CloudFormationテンプレートによって配備された複数のコンポーネントから構成されます。テンプレートはあらかじめ用意されていますが、すべてのリソースの適切なプロビジョニングと細かい必須事項のコンフィギュレーションには、AWSの専門知識がある程度必要になります。つまり、適切なタグ付けから諸々の設定まで、すべては情報の正確性に依存しています。さらに、各コンポーネントのメンテナンスにはオーバーヘッドが生じ、トラブルシューティングも決してシンプルとは言えません。よって、社内に経験豊富な運用チームを擁しているのでなければ、いろいろと手こずる可能性はあります。そして、当然ながら、Instance Schedulerを構成する各サービスの稼働に対して支払いが発生します。LambdaやCloudWatchの運用、DynamoDBの読み取り書き込み作業に対して料金がかかると考えてください。

さらに、もう1点。すべてのコンフィギュレーションはDynamoDBに保存されるので、何か変更するたびにCloudFormationスタックの更新が必要になります。ごく微細な変更を手動でさっと加えるようなことはできません。後々、整合性に問題が生じてしまいます。

代替ツールとしてのN2WS Backup & Recovery

N2WS Backup & RecoveryはN2WSが提供するクラウドネイティブなツールです。主要な特長は、データをすばやくバックアップし、どこにでもリストアできることです。必要なら、AWSアカウントに対しても活用できます。データを災害から守る上で優れた効果を発揮しますが、N2WS Backup & Recoveryの特性はそれだけではありません。リリースごとに新機能と改善が加えられ、最新版のN2WS Backup & Recovery 2.5ではResource Control(リソースコントロール)が備わり、AWS Instance Schedulerに替わるツールとして信頼性が増しました。

AWS Instance Schedulerはインスタンスが常時稼働してしまうのを防ぎ、コストを削減するには効果的なツールですが、セットアップにそれなりの労力がかかり、AWSの実務経験も必要となります。それに対し、N2WS Backup & RecoveryはAWSの経験はほぼ必要なく、迅速かつ容易にセットアップできます。実際、スケジュールの設定作業に時間はかかりません。すべてのインスタンスが一括管理され、他のサービスに依存することもありません。必要な作業はすべて裏で勝手に処理してくれるので、ユーザーはインスタンスのグループを定義し、それらをいつ起動し、いつ停止するのかを選択するだけです。グループ定義されたインスタンスをまるごと1クリックで起動または停止することも可能なので、とても利便性に優れています。

N2WS Backup & Recovery、その他の利点

N2WS Backup & Recoveryは急速にその機能を拡充し、新機能のいくつかは極めて有用性の高いものとなっています。例えば、EBS(Elastic Block Store)スナップショットをAmazon S3に直接アーカイブすることができ、最大で40%のコスト削減をもたらします。他にも、VPC(Virtual Private Cloud)キャプチャー/クローン機能により、VPC全体を他のリージョンにすばやく簡単にレプリケートでき、災害復旧の時間と手間を大幅に節約します。最近では、コマンドラインインタフェース(CLI)を通じてのAPIサポートが拡大され、各種処理の自動化がより設定しやすくなりました。

まとめ

AWSに関しては、どの企業もコスト管理の強化を模索しており、Instance Schedulerはまさにそのためのツールです。しかし、諸々の追加費用と煩雑さなど、すべての要素を考慮すると、Instance Schedulerを最良のソリューションと呼ぶにはほど遠い感があります。一方、N2WS Backup & RecoveryにはAWS Instance Schedulerと同じ機能がすべて備わっていながら、必要な設定作業が格段に少なくて済みます。AWS Instance Schedulerに替わるソリューションとして申し分がありません。他にも多くの機能を備え、アップデートも定期的に適用されるので、小規模な新興企業であろうと、大規模なエンタープライズ環境であろうと、N2WS Backup & Recoveryの導入は十分検討に値します。

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください