The Doppler Quarterly (日本語) 夏 2018 - Page 26

その結果、コンテナーオーケストレーションとサーバーレスが 揮します。ミドルウェアレイヤーは、時間でのアプリケーション 選択肢として残ります。これら 2 つの有効なプラットフォーム パフォーマンスを改善するために最適化できます。さらにサー は、現在および将来の IT 環境にクラウドネイティ が課す要 バーレスではサードパーティAPI やプラグインの統合も簡単に 求に対応できるものとされています。 できます。 コンテナーオーケストレーション ̶ Kubernetes、 ただし、いくつかのデメリットがあります。サーバーレスはまだ Swarm、 Mesos などのプラットフォームにより、 PaaS や他の 成熟していないコンピューティングモデルです。そのため、包括 従来の開発プラットフォームでは不可能なパワーを開発者は手 的で安定したサンプル、ツール、ベストプラクティス、およびド に入れることができます。ポータブルアプリケーションを作成 キュメントが十分に っていません。また、他のプラットフォー し、展開できます。異なる環境向けに再設定し、展開することな ムよりもデバッグが難しくなります。オンデマンドストラクチャの く、どこでも実行できます。 ため、システムがアイドル状態から「コールドスタート」すると、 この機能により、開発者は展開するイメージバージョンの正確 な種類とその展開場所について、非常に高い柔軟性を確保し て管理できます。基本的にインフラストラクチャ全体を監視で き、最終形態、つまり実行中でも、イメージの再利用とコンテナ 問題が発生することがあります。サーバーレスワークロードラン タイムには 5 分間の上限があり、延長するには追加のオーケス トレーションまたはリファクタリングが、複数のマイクロサービ スで必要となります。 化アプリケーションのクラウドへの移動が可能です。 プラットフォームソリューションへの到達 コンテナーオーケストレーションのデメリットは何でしょうか。 それではどのプラットフォームを選択するのか、という問いに一 それは、新しいレベルの複雑さがプロセスに入り込むことで 言で答えられる画一的なソリューションはありません。コンテ す。可用性の高い Kubernetes クラスターの構築は複雑なタ ナーと相性の良いタイプのワークロードもあれば、サーバーレ スクです。コンテナーオーケストレーターを追加していくと、開 ス環境がよく適合するものもあります。それぞれの特性と組織 発者は、サービス検出、ロードバランシング、キャパシティ管 のニーズにより、ワークロードを分割できます。重要なことは、 理、監視、ログ収集、バージョンアップグレード、その他の共通 プロジェクトを準備して適切な質問を提示することです。これ サービスといった、さまざまな対象に多大の注意を払うことを により、最適なマッチングが可能になります。 求められます。つまり開発者は作業で手一杯になるか、 EKS、 Fargate、 AKS、 GKE などのマネージド Kubernetes オーケス トレーターに頼る必要があります。これには、最新バージョン を利用できなくなる点と、ある程度のベンダーロックインが伴い ます。 サーバーレス ̶ サーバーレスプラットフォームでは、コン テナーオーケストレーターより実際上の管理が少なくなりま す。AWS Lambda、 Azure Functions、 IBM Openwhisk な どのツールを使用して、開発チームは特定のイベントに対応す るロジックを少量のコードで記述できます。サーバーレスは基 本的にマネージドサービスです。開発者は、トリガーに応答す るアプリケーションに注力し、オートスケール、パッチ適用、柔 軟なロードバランシングといったインシデントの対応はプラット フォームに任せられるようになります。 これは、利用状況に応じた支払い ( コードが実際に動作して いる時間のみ課金される ) モデルを活用する開発者には非 常に好都合です。また、イベント駆動で予測不能のワークロー ド (IoT、ビッグデータ、メッセージなど ) に対してメリットを発 24 | THE DOPPLER | 2018 年夏号 結論 サーバーレス環境は、新規開発したアプリケーション、クラウ ドに移行するアプリケーション、イベント駆動型のワークロー ド、および多くのスケーリングが必要となるものに最適である という傾向があります。ファイル転送が必要な IoT アプリケー ション、データストリーム、ワークロードストリームも、サーバー レスの良い候補です。さらに、最新の日次運用チームはサー バーレステクノロジーを活用し、ログ解析、自動タグ機能、セ キュリティイベントへの対応、アラーム、および自動スケールな どのタスクを自動化する方法に注目しています。その一方で、ク ラウドの内外に移動する必要があり、多くの管理が必要となる レガシーワークロードは、コンテナーでの実行が適しています。 要件の単位が細かくなればなるほど、コンテナーが魅力的にな ります。 以上が従うべき一般的な考え方です。ただし状況に応じて、ク ラウドネイティブコンピューティングのプラットフォーム・ストラ テジを確定する前に、評価プロセスを組織で実行する必要が あります。