目次


考え方を変えてクラウドの能力を最大限に引き出す

第 2 回 クラウド・ソリューションを機能させる

クラウド対応ソフトウェアを使用してアジャイル開発をサポートする

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: 考え方を変えてクラウドの能力を最大限に引き出す

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:考え方を変えてクラウドの能力を最大限に引き出す

このシリーズの続きに乞うご期待。

第 1 回では、クラウド対応アプリケーションには以下の具体的な特徴があることを説明しました。

  • クラウド環境によって提供されるランタイム機能を利用するために、仮想化を意識した設計になっています。
  • クラウド・インフラストラクチャーをアプリケーション・フレームワークとして使用し、サービス・プロバイダーによって提供されるアーキテクチャー・パターンを別のアーキテクチャーで無効にするのではなく、提供されたアーキテクチャー・パターンを利用します。
  • 存続性を念頭に置いているため、外部ミドルウェアに完全に依存する場合とは対照的に、制御可能な手法を最優先にします。
  • 基礎となる技術リソースを最大限有効に活用するマイクロサービス・アーキテクチャーに従います。
  • ソリューション全体に安定性と予測性をもたらすプラクティスである、不変サーバーとしてデプロイされます。

今回は、以上の原則がクラウド対応アプリケーションの開発にどのように影響するかを見て行きましょう。

クラウド対応ソフトウェアとアジャイル開発

コンピューターが少数の「大規模な」メインフレーム・システムであった (少なくとも、このメインフレーム・システムが占める床面積は「大きかった」) 時代のソフトウェア業界は、その当時の最先端の職人技から「産業」へと移行する方法を模索していました。

今や、私たちは当時のコンピューターより 100 倍強力なコンピューターをポケットに入れて持ち歩くようになっていますが、それでも未だにソフトウェア業界はその当時と同じ課題 ― より正確に言うと、ソフトウェア成果物にとって適切な産業プロセスは何であるかという課題 ― に奮闘しています。

そうこうしている間に、いくつかのモデルが登場し、過度な期待のピークに達した後、幻滅期を経て、現在は概ね安定的に主流のモデルとして使用されるようになっています。こうしたモデルとは、具体的にはウォーターフォール開発、オブジェクト指向、モデル駆動開発、統一プロセス、そしてアジャイルといったモデルです。

現在、まさに主流の手法と見なせるのはアジャイル手法であり、ほとんどの開発現場で何からの形でアジャイル手法が採用されています。アジャイルは開発プロセスを合理化することで、リリース間隔の時間短縮とコスト削減を約束します。最近の「DevOps」、「継続的デリバリー」といった言葉が示唆する新しい手法では、かつて IT 運用と言われていたものと開発がともに関わる、高度に統合されたプロセスを通じて、継続的フローの中で、機能 (ひいては価値) が顧客にデリバリーされます。

継続的デリバリーを実現する

クオリティーを維持しつつ迅速にデリバリーするには、次の 2 つのことが必要になります。

  1. 顧客が要件を提示した時点から、コードを完成させてテストして本番へ移行するまでの全体にわたる効率的なデリバリー・プロセス。このプロセスでは、1 人の開発者が新しいコードを 1 日に複数回アップロードする可能性があるため、ビルドとテストの自動化に多大な投資をしなければならないことを意味します。
  2. 問題があった場合のやり直し作業を最小限にして、短時間での改善を可能にするために、小さなバッチで編成された機能。

このようなプロセスに、クラウド対応ソフトウェアのいくつかの特徴がどのように役立つかを理解するのは、簡単です。まず、マイクロサービス・アーキテクチャーは、デリバリーを小さく分割するのに役立ちます。また、クラウド・プロバイダーのフレームワークをアーキテクチャーのブループリントとして使用することで、自動化されたテストを実行するのも再現するのも容易になります。さらに、不変サーバーの手法により、短時間のデリバリー・サイクルが可能になります。

継続的デリバリー・パイプラインの例 (IBM DevOps Center of Competency のご厚意により掲載)
継続的デリバリー・パイプラインの例を示す図 (IBM DevOps Center of Competency のご厚意により掲載)
継続的デリバリー・パイプラインの例を示す図 (IBM DevOps Center of Competency のご厚意により掲載)

上で説明したプロセスをカスタマイズする方法は、数え切れないほどあります。例えば、「コードの作成 (Write code)」、「コードのコミット (Commit code)」、「ビルドおよびユニット・テスト (Build & unit test)」の 3 つのステップは、サンプル・プロジェクトでは以下のようになります。

開発プロセス
開発プロセスを示す図
開発プロセスを示す図

個人用ビルド (personal build) は、コードが機能していることをデモするために開発者が作成する最初の成果物です。つまり、コードは公式のビルド環境と同じ環境でビルドされ、FVT (Functional Verification Test) テスト・スイートによって自動的にテストされます。FVT テスト・スイートには、リグレッション・テスト・ケースに加え、この新しいコードを検証するために新しく生成されたテスト・ケースも含まれます。

個人用ビルド (personal build) が成功すると (つまり、コンパイル・エラーも FTV エラーもない状態になると)、開発者は同僚にコードのレビュー (Code review) を要請します。

コードのレビュー担当者から何もコメントがなければ、コードをコミットし、本番用ビルド (production build) に移ります。本番用ビルド (production build) では、個人用ビルド (personal build) と同じロジック、そして同じ環境を使用します。最終的な成果物は、共有ドライブに送信されます。

ビルドの結果は自動的にクラウドのステージング環境にインストールされ、そこでさらに自動テストと手動テストが行われてから、一般に使用可能になります。

パイプラインの各ステップでは、パイプラインの自動化に役立つツールを 1 つ以上利用します。次に示す 2 つの図には、上記と同じパイプラインと併せて、オープンソース・コミュニティーや IBM 内部で最もよく使用されているツールと、これらのプロセスおよびツールを最大限活用するために推奨されるアジャイル・プラクティスが示されています。

アジャイルの原則とベスト・プラクティス (IBM DevOps Center of Competency の厚意により掲載)
アジャイルの原則とベスト・プラクティスを示す図
アジャイルの原則とベスト・プラクティスを示す図

 

ツール
ツールを示す図
ツールを示す図

タスクの作成と管理ならびに要件の管理には、RTC (Rational Team Concert) を使用します。開発チームはいくつかの国に分散されているため、情報共有のために IBM SmarterCloud Meetings と IBM Sametime を使用します。本番用コードのコード・リポジトリーは RTC です。さらに、継続的デリバリー固有の成果物を保管するために、Git も使用します。RTC を使用する主な理由は、このツールは使いやすい上に、わかりやすいグラフィカル・インターフェースと強力な履歴追跡機能を備えているためです。ビルドは RTC スケジューラーによって定期的に作成され、Jenkins サーバーを使用してオーケストレーションが行われます。コード・レビューを扱う際には、RTC 承認レコードが使用されます。Git に保管されたコードのレビューと承認には Gerrit を使用します。このパイプラインの興味深い部分は、FVT 環境の生成とそのライフライクルです。

パイプラインの有効性は、その自動化の程度に左右されます。短時間で本番へ移行したければ、手作業でステップを実行する余裕はなく、FVT (Functional Verification Test) と SVT (System Verification Test) を完全に自動化する必要があります (あるいは、少なくとも頻繁に実行しなければならない主要なテスト・ケースを自動化する必要があります)。プロセスでバグを発見するのが遅くなればなるほど、バグ修正にかかるコストは高くなります。

その一方、すべてのビルドに対して完全なテスト自動化スイートを実行すると、ビルド・プロセスの速度を低下させるため、できるだけ頻繁かつ短い期間でビルドを行うことをお勧めします。テスト設計を組み合わせられるという性質は、すべてのビルドで実行しなければならないテスト・ケースの最小セットを見極めるのに役立ちます。さらに、選ばれた製品ビルドに対してテスト・スイート全体が無人で定期的に実行されるようにすることもお勧めします。

顧客の意見を継続的デリバリーに反映させる

従来のソフトウェア開発では、アルファ版およびベータ版のコード成果物を顧客がダウンロードしてテストできる期間が設けられましたが、それと同様に顧客とのやりとりやコード・プレビューも限られた期間で行われました。

ソフトウェアがクラウド内に存在する場合、それとはまったく異なる一連の手法が適用されます。機能要件と非機能要件の両方に関する意見を即座に入手するために、機能をマイクロサービスとして小さなチャンクで顧客にデリバリーします。興味深いことに、明示的に意見を求めることはしません (ただし、そうすることもできます)。例えば、ある特定のユーザー・インターフェース・パネルの設計に対して、どちらのパネルが最適なアプローチであるかを見出したければ、そのパネルの 2 つのバージョンを Web 上に公開し、一方のバージョンを表示できるユーザーと、もう一方のバージョンを表示できるユーザーをロード・バランサーによって分離します。これらのページでのユーザー操作をモニターすれば、どちらのバージョンのほうが適しているのかを判断することができます。

通常、ユーザー操作をモニターするということは、使用状況のデータ (例えば、「ボタン X がクリックされた」、「フィールド Y が変更された」などのデータ) を簡単に抽出できるようにコードをインスツルメント化することを意味します。最も単純な形のインスツルメント化は、ログ・ファイルを簡単にクローリングして複数のログ全体での結果を分析できるようにすることを意味します。

当然、バイナリーに入れられているものの、外部化されていない機能を公開するには、アプリケーションでリリース・トグルを使用する必要があります。さらに、1 つのコンポーネントまたはサービス全体を置き換えても他のサービスは中断されないようなアプリケーション設計になっていなければなりません。これらのシナリオでは、従来のオールインワン・アップデートではなく漸進的なアップグレードを行う必要があるため、冗長性が重要になってきます。

リリースという概念を終わりにする

非クラウド・ソフトウェア世代に属している開発者は、製品リリースを、定期的 (通常は 6 ヶ月または 12 ヶ月ごと) にデリバリーされる新しい機能とアーキテクチャー変更による大きな技術的飛躍として扱うことに慣れています。クラウドの世界では、リリースという概念は時代遅れになっています。これに代わる概念は、「バイナリー差分」です。バイナリー差分は、インストール済みシステムをベースとして頻繁にデリバリーされるため、新規インストール手順が用意されていることよりも、強力なアップグレード手順が設けられていることの方が重要になります。新規インストールは一度しか実行されませんが、その後のステップはすべてアップグレード・ステップになります。

このバイナリー差分の概念は、機能に関する小さな変更であれば単純明快ですが、一般にパフォーマンス、スケーラビリティー、可用性を実現するためのアーキテクチャー上の変更の場合、あまり明白ではありません。例えば、完全に自動化されている継続的デリバリー・パイプラインと、見事なまでに自動化された無人テスト・スイートで、システム・テストと機能テストの両方の観点による全テスト・ケースの 90 パーセントに対処できるとします。その場合、ソフトウェアがクラウド上で実行可能な状態であると十分に確信できますか?数百万人のユーザーにサービスを提供できて、ひと時もサービスが中断されないことを確信できますか?コードが迅速に (場合によっては数分おきに) デリバリーされるというのに、コードにメモリー・リークがないこと、パフォーマンスのボトルネックがないこと、あるいは製品のレジリエンシーや可用性を損なうその他の障害がないことを、どうやって確実にすることができるでしょうか?

私たちの経験では、それには一般に 3 つの方法があります。

  • 自動的かつ定期的に静的コード・スキャンを実行する
  • 負荷と信頼性の状況を焦点とした、長期間実行されるシナリオを定期的に実行する
  • 受け身の態度で、問題が発生したときにだけ対応する

最初の方法は、極めて興味深いものであり、継続的デリバリー・パイプラインの一部にすることもできます。継続的デリバリー・パイプラインに組み込めば、ビルドを n 回行うごとに 1 回非同期で自動的にスキャンを実行し、その結果を分析することができます。従来のコンポーネント化されていないソフトウェアの場合、静的コード・スキャンには数日程度かかるでしょう。コードが十分に分離されておらず、自律コンポーネントとマイクロサービスに分類されていないとしたら、この手法を実現するのは不可能です。また、ライセンスの観点から、信頼性のある静的ソフトウェア・スキャンはコストが高くなりがちです。さらにデータを分析するのに非常に時間がかかり、製品に関する深い知識がなければ実際の問題と誤検出を区別できないことも多々あります。

2 番目の方法では、想定されるワークロードをシミュレートするために大量のハードウェア・リソースが必要になる場合があります。また、テストが完了するまでに数日かかる場合もあります。多くの人々にとって、継続的デリバリーのシナリオでビルドごとにこの方法を実行するだけの余裕はありません。選択したビルドに対してだけこの方法を適用することもできますが、ビルドの準備ができたら (すべての自動テストに合格したら)、そのビルドをインストールして、長時間実行されるシナリオを実行する必要があります。そこで何か問題が見つかった場合、その問題を分析して解決し、再ビルド、再テストなどを行う必要があります。

意外なことに、クラウドの世界では多くの場合、3 番目の方法が最も妥当な方法になります。問題が発生するまで何もせず、問題が発生したら素早く解決するという方法です。これは、クラウドの世界での高可用モデルに似ています。つまり、あらゆるタイプの問題に耐えられるソフトウェアを作成するのではなく、問題発生時に素早くリカバリーできるだけのレジリエンシーを備えたソフトウェアを作成するというモデルです。

コードは Web 上に公開されて、(通常は、クラウド・サービス・プロバイダーのインフラストラクチャーに用意されているロード・バランサーとプロキシーを通じて) 限られたユーザーだけが入手できるようになります。そしてオペレーターがパフォーマンスをモニターして最もよく使われている機能を確認できるように、コードはインスツルメント化されます。

  • すべてが計画通りに運んでいれば、ロード・バランサーが再構成されて、さらに多くのユーザーにまで対象が拡大されます。
  • 異常が検出された場合は、開発チームにそれが知らされて、異常の解消に取り掛かるために必要となる適切な測定データが提供されます。

修正版が用意できたら、その修正の影響を受ける VM の新しいバージョンの「不変サーバー」を再起動することで、同じ一連のユーザーに対してその修正版が配布されます。このプロセスが、ユーザーのすべてに同じコード・レベルのアプリケーションが表示されるようになるまで進められます。

まとめ

この記事では、第 1 回で説明したクラウド対応アプリケーションの特徴が、本番に向けた機能の継続的デリバリーによる真のアジャイル開発をどのように促進するかを説明しました。第 3 回では、実際のプロジェクトでの私たち独自の経験を検証し、共通する課題と経験から学んだ教訓について説明します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=1028995
ArticleTitle=考え方を変えてクラウドの能力を最大限に引き出す: 第 2 回 クラウド・ソリューションを機能させる
publish-date=04072016