ビルド プロセス用の Azure テクノロジ

  • 10 分

ここでは、イノベーション プロセスと、アプリケーションに新しい機能を組み込むのに役立つ業界のいくつかのテクノロジとの関係について説明します。

DevOps

ビルド フェーズを開始してイノベーション仮説を検証したら、必要な開発、統合、およびデプロイ サイクルを可能な限り合理化する必要があります。 このフェーズで DevOps の出番となります。 DevOps は、"ソフトウェア機能を迅速かつ確実に提供するためのプロセスとツール" として定義できます。この定義の詳細を次に示します。

  • プロセスとツール: イノベーション プロセス全体としての DevOps は、変更を促進する文化パターンに基づいています。 Azure と GitHub は DevOps に関する優れたツールを提供していますが、ライセンスを購入するだけでは十分ではありません。 変更とイノベーションを採用するために、プロセスと組織文化が進化する必要があります。

  • ソフトウェア機能の迅速な提供: DevOps のプロセスとツールは、フェイル ファストの概念を採用しています。 MVP またはプロトタイプをビルドして、作業中の機能が正しい方向に進んでいるかどうかをすばやく検証することは、DevOps の概念の中核となります。

  • ソフトウェア機能の確実な提供: 変更を好まない組織は、迅速な変更をダウンタイムと結び付けて考えることがよくあります。 しかし、DevOps は正反対のもの、つまり、迅速な変更率と高レベルの信頼性を約束します。 この信頼性は、"シフト レフト" と呼ばれるプロセスである開発サイクルの初期段階でテストを統合することによって実現可能になります。

    時間の経過に伴う機能の開発を、左から右へのラインとして見た場合。 その場合、レガシ開発プロセスでは、開発サイクルの最後にユーザーの検証と品質管理を実行します。 そのラインの "右" 端。 DevOps では、できるだけ早い段階で、そのタイムラインの「左」側からテストと検証を行うように推奨されています。

DevOps は、健全なイノベーションの文化と同じコア概念を具体化しています。 この手法を採用することで、アジャイル イノベーション サイクルを実現できます。

マイクロサービス アーキテクチャ

モジュール性は、複雑なシステムを設計する際の複雑さを軽減するためのよく知られた手法です。 システムが、分離できない多数の部分の複雑な相互作用である場合 ("モノリス" と呼ばれることが多い)、厳密なコンポーネントの相互依存によってシステムの改善が困難になります。 すべての変更はシステムの他の部分とともに検証する必要があるため、テスト プロセスが複雑になります。

システムがモジュール式の場合、明確に定義されたインターフェイスを使用して相互にやり取りする小さいサブシステムに分割できます。 これらのサブシステムのいずれかで変更を導入するのは簡単です。他のモジュールとのインターフェイスが変わらない限り、システム全体が動作し続けるからです。

マイクロサービス アーキテクチャは、モジュール性を利用するアプリケーション パターンです。 アプリケーションは、互いに独立して開発でき、異なるプログラミング言語を使用する場合もある、個別の小さなコンポーネントに分割されます。 各コンポーネント (マイクロサービス) は独自に操作できます。 必要に応じて拡張でき、1 つのユニットとしてトラブルシューティングでき、他のマイクロサービスとは別に変更することができます。

組織からよく聞かれる質問は、アプリケーションがモノリシックである場合の対処方法です。 組織は、イノベーションを導入する前にアプリケーションをマイクロサービス アーキテクチャに再設計する必要があるのでしょうか? または、イノベーションと再設計のプロセスは並行して実行できるのでしょうか? この質問に対する答えは 1 つではありません。 検討中のアプリケーションの複雑さとビジネスの関連性によって異なります。

Tailwind Traders 社は、eコマース プラットフォームにイノベーションを導入する際にこの質問に直面しました。 同社は、eコマース アプリケーションをマイクロサービス アーキテクチャに再設計するプロジェクトを開始することを決定しました。アプリケーションのビジネス上の重要度がこの取り組みを正当化するためです。 モジュール型のアプリケーションを用意していないと、オンライン市場の絶えず変化する傾向に対応する Tailwind Traders 社の能力が大幅に損なわれます。

しかし、Tailwind Traders 社は、プラットフォームの主要なギャップのいくつかに同時に取り組むことを決定しました。 アプリケーションの再設計プロジェクトが完了するのを待つことは、現在 eコマース市場を一変させている新しいスタートアップに大きな市場シェアを奪われることを意味するからです。

これらのプロジェクトは、イノベーションのビジネス価値に基づいて相互作用します。 再設計作業では、カスタマー エクスペリエンスを改善するために変更する必要性が最も高い、最も重要なアプリケーション領域に焦点を当てます。

コンテナー

コンテナー化のテクノロジは、マイクロサービス アーキテクチャに限定されていませんが、概念は連携します。 コンテナーは、任意のプラットフォームで簡単にデプロイできるように、アプリケーション コードとその依存関係をカプセル化する方法です。

従来のアプリケーションのデプロイでは、組織は最初に、アプリケーション ランタイム、プログラミング ライブラリ、外部コンポーネントなどのソフトウェアをインストールする必要があります。 このアプローチは、多くの場合、「自分のマシンで機能する」という問題に起因します。開発、テスト、ステージング、および運用環境で同じ環境をレプリケートすることは困難です。 アプリケーションの依存関係のインストール方法に小さな違いがあると、テスト中はアプリケーションが正常に動作しますが、運用環境にデプロイすると失敗することがあります。

コンテナーはゲームのルールを変更します。 アプリケーションの依存関係は、コンテナー イメージと呼ばれている自律型デプロイ ユニットのアプリケーション コードと一緒にパックされます。 アプリケーション コンテナーが開発者のノート PC にデプロイされているか、数百のノードを持つ運用クラスターにデプロイされているかにかかわらず、依存関係の処理はまったく同じです。 コンテナーはまったく同じように機能するので、アプリケーション テストの信頼性がより高くなります。

Docker が 2013 年にオープンソースとしてコードをリリースして以来、コンテナーは長い道のりを歩んできました。 コンテナーでは、Linux および Windows の両方と、さまざまな CPU アーキテクチャがサポートされるようになりました。 Azure には、コンテナーベースのワークロードを実行するための多くのオファーが用意されています。 このユニットでは、その一部について説明します。

Kubernetes と Red Hat OpenShift

コンテナー ランタイムは、コンピューターでコンテナーを起動するテクノロジですが、運用環境ではより多くのロジックが必要です。 より多くのパフォーマンスが必要な場合、誰がより多くのコンテナーをデプロイするのでしょうか? 問題が発生した場合に、誰がコンテナーを再起動するのでしょうか? 複数のコンピューターが使用可能な場合、特定のコンテナーを起動するコンピューターを誰が決定するのでしょうか? これらのタスクとその他のタスクは、コンテナー オーケストレーション プラットフォームがその役割を担います。

最初のバージョンの Kubernetes は 2015 年にリリースされ、すぐにコンテナー オーケストレーションの事実上の標準になりました。 Kubernetes クラスターは複数のワーカー ノードで構成されています。 それぞれのワーカー ノードがコンテナー ランタイムを持つため、コンテナーを実行できます。この場合、Kubernetes コントロール プレーンは、コンテナー化されたアプリケーションのデプロイをスケジュールします。 このコントロール プレーンは、通常、一連のコア ノードで実行されます。 これは、アプリケーションが正しく動作している状態を維持し、アプリケーションのスケールアップまたはスケールダウンを行い、必要な更新プログラムを実行する役割を担います。

Kubernetes が普及している主な理由の 1 つは、コンテナーが提供するハードウェアの独立性にあります。 コンテナーベースのアプリケーションは任意のコンテナー ランタイムに確実にデプロイできるため、さまざまなハイパーバイザーを使用するクラウドで Kubernetes を実行できます。 デプロイされたアプリケーションは同様の方法で動作します (基になるハードウェア リソースが類似していることを前提とします)。 多くの組織は、オンプレミスとパブリック クラウドの両方で一貫したアプリケーション デプロイ プロセスを可能にする抽象化レイヤーとして Kubernetes を採用しています。

Azure での Kubernetes の実行は簡単です。 Azure Kubernetes Service は簡単にデプロイでき、お客様にはワーカー ノードのコストのみが請求されるため、コスト効率が高くなります。 コア コンポーネントを含むコントロール プレーンのコストと運用は、Microsoft が担います。 Microsoft は、ワーカー ノードのオペレーティング システムの修正プログラムの適用と更新を行います。これにより、Linux および Windows コンテナーを実行するための Kubernetes クラスター管理の運用上の複雑さがさらに軽減されます。

OpenShift は、Kubernetes に基づくアプリケーション デプロイ プラットフォームであり、Red Hat によって開発およびサポートされています。 他の多くの機能が組み込まれています。 OpenShift でアプリケーションを実行することを選択した組織の中には、これらの追加機能と Red Hat によって提供されるサポートのためにそうするものがあります。 Azure で OpenShift を実行することは簡単です。 Azure Red Hat OpenShift は、クラスターのライフサイクル全体など、機能の多くが Microsoft によって管理されている OpenShift クラスターで構成されています。

Azure App Service

Azure App Service は、組織がオーケストレーターや基盤となるオペレーティング システムを管理することなく、Web ベースのワークロードを実行できるプラットフォームです。 唯一の要件は、利用可能な多くのデプロイ方法の 1 つを介してサービスにアプリケーション コードをアップロードすることです。 アプリケーションのスケールインとスケールアウト、基になる仮想マシンの修正プログラムの適用と保守など、残りは Azure で行われます。Kubernetes の学習は必要ありません。

Azure App Service はコンテナーベースのワークロードをサポートするため、アプリケーション コードの代わりにコンテナー イメージをアップロードできます。 また、Linux と Windows のワークロード、およびさまざまなアプリケーション ランタイムもサポートしています。

Azure App Service では、Azure Functions と呼ばれるサーバーレス オプションを含むさまざまな価格モデルがサポートされています。 Azure Functions では、アプリケーションの使用量のみが課金されます。 固定費はありません。

サーバーレス モデルは、市場で受け入れられない場合に、月単位の高額な請求を発生させることなく新しいマイクロサービスをデプロイできるため、イノベーションにとって興味深いものです。 このモデルは、イノベーションが高いコストを意味するとは限らない、フェイルファスト戦略のもう 1 つの例です。

Azure App Service には、Web アプリ スロットなどの DevOps 指向デプロイをサポートする機能も用意されています。 スロットはステージング領域であり、運用環境に影響を与えることなく、新しい機能をデプロイできます。 スロットは、イノベーションの観点からは非常に優れています。なぜなら、少数のお客様をこの新しいバージョンのアプリケーションにリダイレクトできるからです。 その後、イノベーションの仮説が正しいかどうかを検証できます。 最終的に、新しいコードを運用環境に昇格する場合は、スロットを「スワップ」して、ステージング環境が実稼働バージョンになるようにします。

まとめ

ここでは、テクノロジがイノベーションをサポートする方法を説明しました。

  • DevOps のプロセスとツールにより、開発チームと運用チームは、新しい機能を迅速かつ確実に提供できるようになります。
  • アプリケーションをマイクロサービスに再設計し、他のコンポーネントに影響を与えることなく、コンポーネントを個別に革新できます。
  • コンテナーを使用すると、複数のプラットフォームや環境での信頼性の高いアプリケーションのデプロイが可能になります。
  • Kubernetes は、コンテナー化されたアプリケーションを実行するためのクラウドに依存しないオーケストレーション プラットフォームです。
  • Azure App Service では、最小限の管理オーバーヘッドで Web ベースのワークロードを実行できます。 サーバーレスやアプリケーション スロットなどの多くの機能を備えており、イノベーション サイクルを高速化することができます。

Tailwind Traders 社は、eコマース アプリケーションのマイクロサービス アーキテクチャへの再設計を開始することを決定しました。 "モノリス" から分離される最初のアプリケーション サブシステムは、支払いサービスです。これは、競合他社が顧客により良い価値を提供している重要な領域として特定されているためです。

支払いサブシステムの後、より多くのアプリケーション コンポーネントが独立したマイクロサービスに変換されます。 マイクロサービスは REST API を介して通信できます。 各マイクロサービスのアプリケーション コードはコンテナー化され、開発と運用の組織は DevOps のベスト プラクティスを採用します。

Tailwind Traders 社は特定のパブリック クラウドに依存しないようにするため、Kubernetes の専門知識を社内で築いて、アプリケーションを Azure Kubernetes Service クラスターにデプロイすることを決定しました。 新しいマイクロサービスを開発する必要がある場合、同社は、開発コストを削減するために Azure Functions を MVP のデプロイのためのプラットフォームとして検討することを選択しました。

次に見る部分

このユニットの概念の多くは、クラウド導入フレームワークの記事の「デジタル発明で採用を強化する」と「クラウド導入フレームワークにおける Kubernetes」で詳しく説明されています。