サイトアイコン TestRail Blog

すべてのパフォーマンスエンジニアが身につけるべき3つのクラウドコンピューティングスキル

この記事はBob Reselmanによるゲスト投稿です。

エフェメラルコンピューティングとは、必要に応じて仮想コンピューティング環境を作成し、目的が達成され、リソースが必要なくなったら破棄するというプラクティスです。コストは使った時だけ、使った分しかかかりません。エフェメラルコンピューティングが提供する価値は無視しがたいものです。

ただし、エフェメラルコンピューティングには利点だけでなくリスクもあります。

しばらく前、私が携わっていたプロジェクトは、短時間に複雑な複数のアルゴリズムを実行し、関係者に結果を送信するというものでした。まさにエフェメラルコンピューティングに適したケースです。そこで私は、クラウドにコンピューティング環境を立ち上げ、コードを注入し、テストが完了したら環境を破棄するという手順で作業を進めました。Google Cloud を利用し、手作業で一連の処理を行いました。すべて計画どおりにうまくいっていました。

ところがある日、私はへまをしました。テストが完了した後、テスト環境を削除するのを忘れていたのです。実は、私は気づいていませんでしたが、テスト環境はその月の終わりまで確保されたままでした。月末になって、Googleから40ドルほどの請求書を受け取りました。ちょっとした驚きでした。いつも、コンセプトの検証に使うだけなら4ドルくらいしかかかりません。調べてみると、コンピューティングセッションをシャットダウンし忘れていたのが、予想外のコストがかかった原因でした。

莫大な金額というわけではありませんが、問題はそこではありません。私が実装したエフェメラルコンピューティングのシナリオは、スーパーコンピューター級の馬力で処理に1時間はかかる大規模なシステムのコンセプトを検証するためのものでした。もしコンセプトの検証段階ではなく本番の実装に入っていたなら、ささいな見逃しが2万ドルのコストにつながったかもしれません。2万ドルといえば、AWSでIntel Xeon E7 8880 v3プロセッサ4つ、最大128仮想CPU、3,904GiBのDRAMベースのメモリを使用する仮想マシン1か月分の費用です。これは相当な金額です。

さいわい、私はエフェメラルコンピューティングを利用するうえでの教訓を得ました。パフォーマンステストシナリオでは、運用環境をエミュレートできるだけの演算能力を必要とするので、エフェメラルコンピューティングは特に有用なアプローチです。しかし、よく考えずにエフェメラルコンピューティングを利用すると、本来避けられたはずの想定外のコストがかかる可能性があります。

私が学んだのは、エフェメラルコンピューティング技術を安全に利用したいなら、3つのスキルが必須だということです。エフェメラルコンピューティングのメリットを活用したいなら、以下を知る必要があります。

では、それぞれのスキルを詳しく見ていきましょう。

スケールコストを見積もる方法

エフェメラル環境を立ち上げると、メーターが動き出します。意図していようといまいと、メーターが動いている時間が長いほど費用がかかります。月末にクラウドプロバイダーから莫大な請求を受けてびっくりしたくないなら、始める前にコンピューティング環境のコストを知っておくのがよいでしょう。

料金計算機能を利用し、意図したエフェメラルコンピューティング環境を実際に実行したときにかかる費用を見積もることを習慣にするようおすすめします。一般的なクラウドサービスには必ず計算機能が用意されています。AWSGoogle CloudAzureそれぞれに計算機能があります。計算機能をよく使う定番のツールにするべきです。

料金計算機能では、1つあるいはそれ以上の環境構成を作成できます。構成を設定すると、一定期間―通常は1か月―のプロジェクトのコストがレポートされます。(図1を参照)

図1: 料金計算機能の例: (1) AWS、(2) Google Cloud、(3) Azure

作業を始める前に料金計算機能を使用するのを習慣づけると、多くの企業でありがちな、月末の請求に驚かされる事態を防ぐのにおおいに役立ちます。

エフェメラルコンピューティングセッションをスクリプト化する方法

手動でエフェメラルコンピューティング環境をプロビジョニングするのは、感覚をつかむための最初の一歩としては手軽な方法ですが、問題のもとでもあります。さきほど説明した私の見落としを考えてみてください。私は環境を立ち上げて、それを破棄するのを忘れていました。少しのメモリの浪費が費用を発生させ、利益は何もありません。手動でエフェメラル環境をプロビジョニングする場合、このようなちょっとした間違いは珍しくありません。

人間というものは、設計にはすばらしい創造性を発揮しますが、反復作業に関してはおそろしいほどあてになりません。スクリプト化は反復につきものの問題を解決します。マシンは指示されたことを毎回同じように実行します。同じプロビジョニングタスクを繰り返すのが3回目になったら、プロセスをスクリプト化するべき時かもしれません。

概念的には、エフェメラルコンピューティングのパターンは比較的単純です。環境を作成し、コードを注入し、コードをテストして環境を破棄します。(図2を参照)

図2: エフェメラル環境を作成してそこでテストするというのは、すでに標準デザインパターンになっています。

もちろん、悪魔は細部に潜んでいます。スクリプトでコンピューティングインスタンスを作成するには、特定のクラウドプロバイダーが提供するツールを利用しなければならないのが普通です。たとえば、Google Cloudで仮想マシンを作成する場合、Google Cloud SDKが必要です。Amazon Web ServiceAzure、その他の独立系パブリッククラウドプロバイダーでも同様です。いったん仮想マシンを作成した後は、Linuxならセキュアシェル(SSH)、WindowsならWinRMなど、標準的なツールを使用してリモートマシンにアクセスするスクリプトを作成できます。後は、スクリプト化されたコマンドをリモートアクセス経由で実行するだけです。スクリプトでは、アプリケーションや依存モジュールのセットアップ、テストの実行などを行うことができます。テストが完了するか演算の目的が達成できたら、適切なSDKを使用してコンピューティング環境を破棄します。

エフェメラル環境をスクリプト化する方法を学ぶのは、とくにSDKを使用してクラウドサービスを操作するのに必要な基本的プログラミングスキルがない場合、多少時間がかかるかもしれません。けれど、いったん覚えてしまえば、非常に効率的だというのがわかるでしょう。また朗報としては、AnsibleChefPuppetなど多数の優れたプロビジョニングツールがあり、エフェメラル環境のスクリプト化に伴う労力を軽減してくれます。

オーケストレーション技術を利用する方法

スクリプト化は有用ですが、とくに多数のコンポーネントや依存モジュールを含む複雑なコンピューティング環境を作成するとなると、作成に膨大な時間がかかる可能性もあります。オーケストレーションはこれを容易にします。

スクリプト化がレシピを扱うものだとすれば、オーケストレーションはケーキ自体を扱います。端的に言えば、オーケストレーションとはシステムを定義することであり、その後、定義に従ってシステムを作成するようKubernetesDocker SwarmMesosphereなどのオーケストレーションテクノロジーに指示することです。(図3を参照)

図3: スクリプトは手順に従ってエフェメラル環境を作成するいっぽう、オーケストレーションは宣言的に環境を作成します。

概念的には、スクリプトを使用したアプローチでは、コンピューティング環境を作成する手順を定義し、順次実行します。いっぽう、オーケストレーションを使用したアプローチでは、システムの特性を定義します。この特性はシステムステートと呼ばれます。システムステートを定義したら、オーケストレーションテクノロジーはステート定義に従ってシステムを作成するだけでなく、そのステートを維持してくれます。つまり、何らかの理由でコンピューティング環境のリソースの1つが利用できなくなった場合、オーケストレーターが自動的にリソースを補充します。

オーケストレーションは、コンテナーをエフェメラルコンピューティングのシーンの中央前面に据えます。コンテナーは、仮想マシンと同じように独立していますが、仮想マシンより軽量ですばやく配置でき、ホストのコンピューティングリソースをより効率的に利用できます。1つのVMが数十、ときには数百のコンテナーをホストできます。また、コンテナーは特定のコンピューティングのニーズにきめ細かに対応することを可能にします。実際、コンテナーは多くのマイクロサービスアーキテクチャの原動力となっています。

単なるプロビジョニングではなくコンテナーベースのオーケストレーションを利用するメリットは、システムの運用の信頼性が大幅に向上することです。また、オーケストレーションテクノロジーは複雑なシステムの作成、維持、破棄に伴う煩雑なタスクを引き受けてくれます。人間はシステムを定義するだけで、オーケストレーションテクノロジーが定義どおりにシステムを作成します。

ただし、新しいアプローチの常として、オーケストレーションの場合も学習が必要です。Kubernetesなどのテクノロジーの学習は大変に思えるかもしれませんが、費やした時間は無駄にはなりません。私がさきほど述べたプロジェクトでオーケストレーションテクノロジーを使っていたとしても、やはりスクリプトは作成しなければならなかったでしょうが、その範囲はコンテナーをホストするVMの作成、オーケストレーターの実行、処理の実行と最後のVMホストの破棄だけに限られていたでしょう。そのとおり、デザインパターンは図2で示したスクリプト化の場合と同じですが、オーケストレーションを利用することでかなりプロセスが簡略化されます。

すべてを組み合わせる

エフェメラルコンピューティングはたしかにコンピューティングの未来です。テストとテスト技術者にとってもますます重要になっていくでしょう。アプリケーション開発者やシステム管理者が企業のデジタルリソースの管理者としての役割を引き受け、知識を深めているのと同様に、リソースが意図したとおり動作し続けるよう保証することはテスト技術者の役目になるでしょう。現在のテスト技術者にとって、エフェメラルコンピューティングの基礎に関して実践的な知識があることは、単に望ましいスキルというだけではありません――必須のスキルです。

筆者のBob Reselmanについて:全国的に著名なソフトウェア開発者、システムアーキテクト、業界アナリスト、テクニカルライター/ジャーナリスト。コンピュータープログラミングに関する書籍のほか、ソフトウェア開発テクノロジーおよびテクニック、ソフトウェア開発カルチャーに関する記事を多数執筆。元Cap GeminiのPrincipal ConsultantおよびコンピューターメーカーGatewayのPlatform Architect。ロサンゼルス在住。現在は、ソフトウェア開発およびテスト活動のかたわら、自動化が雇用に与える影響に関する書籍を執筆中。連絡はLinkedInwww.linkedin.com/in/bobreselmanまで。

(この記事は、開発元Gurock社の Blog 「The 3 Ephemeral Computing Skills Every Performance Test Engineer Needs to Have」2019年2月6日の翻訳記事です。)

モバイルバージョンを終了