これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
こんにちはー。野田貴子です。今回は海外で公開されているOpenStack関係のコラムを意訳します。英語が苦手な方にとっては、日本語で要約版があると助かるのではないかと考え、日本語訳したものをご紹介いたします。
興味がある方はご参考ください。海外動向を理解する上での参考になれば幸いです。
さて今回の記事は、現代のソフトウェア産業であるクラウドネイティブアプリケーションの主要テーマに光を当て、実用的な情報を公開することを目指している二部構成のブログ記事の一つ目となります。この記事ではマイクロサービス、コンテナ、そしてサーバーレスアプリケーションについて言及していきます。そしてこれらの技術の実用面における長所と短所について説明します。
クラウドネイティブアプリケーションは現代のソフトウェアアプリケーションを構築するための強力なアプローチであると世間では言われていますが、マイクロサービスとは何でしょうか？ マイクロサービスは、ソフトウェアアプリケーションに必要な機能を複数の小さな独立したソフトウェアサービス、あるいは「マイクロサービス」に分離するという発想のことです。それぞれのマイクロサービスは各々のタスクを専任します。マイクロサービスが連携して大規模なアプリケーションを形成するために、それらはお互いに通信し、データをやり取りします。
マイクロサービスはモノリシックアプリケーションの複雑さと非柔軟性から解放されました。モノリシックアプリケーションとは、すべての必要な機能が同じサービスの中で一同にコーディングされているアプリケーションのことです。たとえば、支払処理とイベント予約を行うモノリシックなイベント予約アプリケーションは次の図で表されます。
このアプリケーションは顧客がコンサートやショーを予約するために使用します。ユーザーインターフェイスが必要です。さらに、イベントを探す検索機能、ユーザーの予約を処理して保存する予約ハンドラー、イベントを探し、空席を確認し、予約へのリンクを示すイベントハンドラーも必要です。製品版のアプリケーションでは支払い処理のようなタスクも必要になりますが、ここでは上記の4つの機能について見ていきましょう。
このモノリシックアプリケーションは、小規模から中規模の負荷のとき適切に動作します。このアプリケーションは単一のサーバー上で動き、単一のデータベースに接続し、おそらく単一のプログラミング言語で書かれます。
ビジネスが急速に拡大し、何千あるいは何百万人ものユーザーを取り扱って処理する必要が出てきた場合はどうなるでしょうか。まず短期の解決策としては、アプリケーションを実行しているサーバーが高負荷に耐えられる強力なスペックであることを確かめ、そうでない場合は、サーバーに追加のメモリ、ストレージ、処理能力を追加します。これをバーチカルスケーリングと言って、負荷の高いアプリケーションを動かすためにRAMやハードドライブの能力といったハードウェアを増強することを指します。しかしこの方法は、アプリケーションを成長させ続けるための対策として長期的に続けられるものではありません。
モノリシックアプリケーションのもう一つの課題は、一つか2つの言語に限定されているために生じる柔軟性の低下です。この柔軟性はアプリケーションの全体的な品質と効率に影響する可能性があります。たとえば、node.jsはWebアプリケーションを構築するための一般的なJavaScriptフレームワークであり、R言語はデータサイエンスアプリケーションの構築において一般的です。モノリシックアプリケーションでは両者の技術を統合するのが困難であるのに対し、マイクロアプリケーションサービスではR言語で書かれたデータサイエンスサービスとNode.jsで書かれたWebサービスを簡単に構築できます。
マイクロサービス版のイベントアプリケーションは次の形式をとります。
このアプリケーションは、ホリゾンタルスケーリングと呼ばれる方法を用いて複数のサーバー間でスケーリングすることができます。各サービスはそれぞれのサーバーあるいは分断されたコンテナに専用のリソースと共にデプロイできます（詳細は後ほど説明します）。さまざまなサービスを異なる言語で書くことができるので、別々の専用チームがそれぞれのサービスに専念し、アプリケーションの全体的な質の向上につながります。
マイクロサービスを使用することのもう一つの顕著な利点は継続的なデプロイの容易さです。これにより、ソフトウェアを頻繁に、いつでもデプロイすることができます。マイクロサービスがこれを得意とする理由は、モノリシックアプリケーションに比べて、新たにデプロイされる機能が他のマイクロサービスに影響を与える可能性が低い点です。
マイクロサービスに大きく依存することの顕著な欠点の一つは、長期運用によってサービスの数や規模が拡大したときに、複雑すぎて管理しきれなくなるかもしれないという事実です。Prometheusのような監視ツールを利用して問題を検出したり、Dockerのようなコンテナ技術を利用してホスト環境の汚染を避けたり、サービスの過剰設計を避けることでこの問題を軽減する方法があります。しかしながら、これらのアプローチには労力と時間が必要です。
マイクロサービスのアーキテクチャはクラウドネイティブアプリケーションに最適です。クラウドネイティブアプリケーションとは、クラウドコンピューティングのアーキテクチャのために何から何まで構築されたアプリケーションと定義できます。これはつまり、あるアプリケーションを分散型でスケーラブルなインフラストラクチャにデプロイされるように設計した場合、そのアプリケーションはクラウドネイティブであるということです。
たとえば、冗長なクラウドネイティブアプリケーションを用いたアプリケーションを構築すると（後ほど例示します）、その構造のおかげでこのアプリケーションをスケーラブルでほぼ常時利用できる分散方式でデプロイできるため、このアプリケーションはクラウドネイティブになります。クラウドネイティブアプリケーションは常にAWSのようなパブリッククラウドにデプロイする必要はなく、用意があれば独自の分散クラウド型インフラストラクチャにデプロイすることもできます。
実は、アプリケーションを完全にクラウドネイティブ化するためには、マイクロサービスを使用するだけでは足りません。アプリケーションは継続的に配布される必要があります。つまり、製品アプリケーションを問題なくアップデートし続ける機能が必要です。アプリケーションにはメッセージキューやコンテナのような技術や、サーバーレスなどのサービスも必要でしょう（コンテナやサーバーレスなど現代のソフトウェアアーキテクチャーにとって重要なトピックがあるので、以降のセクションで解説します）。
とりわけ、クラウドネイティブアプリケーションは予めインストールされたソフトウェアサービスにアクセスするため、多数のサーバーノードへのアクセスや、継続的な配布サービスとの統合のしやすさを前提としています。
クラウドネイティブアプリケーションをAWSやAzureアプリケーションのような商用クラウドにデプロイする場合、クラウド限定のソフトウェアサービスを使用する選択肢があります。たとえば、DynamoDBは製品アプリケーション用のAmazon Web Servicesでしか使用できない強力なデータベースエンジンです。AzureのDocumentDBデータベースもあります。 Amazon Simple Queue Service（SQS）といったクラウド限定のメッセージキューもあり、SQSはAmazon Web Servicesクラウドにおけるマイクロサービス間の通信を可能にします。
前述のように、クラウドネイティブのマイクロサービスはサービス間の冗長性を可能にするように設計する必要があります。イベント予約アプリケーションを例としてあげると、アプリケーションは次のようになります。
複数のサーバーノードがマイクロサービスごとに割り当てられ、冗長なクラウドネイティブアプリケーションがデプロイされます。何らかの理由で第一のノードやサービスに障害が発生した場合は控えが引き継ぐため、クラウドネイティブアプリケーションの信頼性や可用性が損なわれることはありません。この可用性は、ダウンタイムが大量の収益の喪失につながる電子商取引プラットフォームなどのフォールトイントレラントなアプリケーションにとっては不可欠です。
クラウドネイティブアプリケーションは開発者、企業、そしてスタートアップにとって大きな価値をもたらします。
マイクロサービスとクラウドコンピューティングの話題の中でぜひとも伝えておきたいツールはPrometheusです。Prometheusは複雑なクラウドネイティブアプリケーションに対して使用されるオープンソースのシステム監視およびアラートツールで、何かしらのアクションが必要なときにアラートをします。PrometheusはもともとSoundCloudによってシステムを監視するために作成されましたが、その後独立したプロジェクトに成長しました。このプロジェクトは現在Cloud Native Computing Foundationに含まれています。この財団はクラウドネイティブアプリケーションのための持続可能なエコシステムを構築する役割を担っています。
クラウドネイティブアプリケーションは、アプリケーションの全てまたは一部を統合する必要が出てきた際に、いくつかの課題に直面します。これはアプリケーションがデプロイされている場所によって原因が変わります。
たとえば、クラウドネイティブアプリケーションがAWSなどのパブリッククラウドにデプロイされている場合、クラウドネイティブ APIはクロスクラウドプラットフォームではないことが問題です。つまり、アプリケーションで使用されているDynamoDBデータベースAPIはAWSのみで動作し、Azureでは動作しません。これは、DynamoDBがAWS専用であるためです。 DynamoDBは本番環境のAWSでのみ使用できるため、このAPIはローカル環境でも動きません。
別の原因は、クラウドネイティブアプリケーションを構築した際に、必要であれば利用できるサーバーノードが事実上無制限になりうることや、迅速に新しいサーバーノードを利用可能にできることなどが前提になっていたということです。これらの前提によって、現物のサーバーやネットワークハードウェア、配線を購入する必要があるローカルデータセンター環境での動作を保証することが難しくなります。
第一部はここで終了です。第二部では、実際の利点や制限とともに、コンテナやサーバーレスアプリケーションについて紹介します。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
