分散クラウドを活用して不要なアプリの統合をなくすには

記事をシェアする:

この投稿は、2021年3月17日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。

分散クラウドは、オンプレミス、クラウド、エッジなど、さまざまなクラウド環境間で一貫したサービスを提供することにより、多くのIT課題を解決します

世界は、より多くのクラウド・ネイティブ（またはクラウドにとらわれない）機能を使用する方向にシフトしています。クラウド環境に関係なく同じように動作するKubernetesのようなオープンソース技術もたくさんあります。クラウド・ネイティブ・アプリは本質的に統合が容易なので、ゼロから始めることは今日では容易です。しかし、ほとんどの企業はゼロからのスタートではなく、オンプレミスのデータセンターや異なるクラウド環境にある既存のアプリケーションとクラウド・ネイティブ機能を統合することが課題となることも少なくありません。

このことをより深く追求する前に、アプリケーションの統合の基本を理解することが重要だと考えています。そして、この必要性の高まりが、なぜDevOpsチームに大きな課題をもたらすのかを理解することが必要です。

 

アプリケーションの統合の例

1990年代から2000年代初頭にかけて、多くの業界固有のツールや機能によって、お客様は特定のベンダーに縛られていました。アプリケーションを構築するために使用されるすべてのプロプライエタリなツールのため、この状況を脱出するのは困難でした。

でも、どうでしょうか？人々はとにかくそれを実行しました。今日、こうした企業では、異なるチームが異なるツール（例えば、Apache Tomcat® と JBoss®）でアプリを実行しています。そこで必要となるのが統合です。

統合には主に3つの方法があります:

1. アプリケーション・プログラミング・インターフェース(API):APIがなければ、現在のほとんどのソフトウェアは存在しません。しかし、APIは単にデータへのアクセスを提供するだけではなく、アプリケーション同士がどのように相互作用するかという仕組みを管理しています。そのため、標準化されたルール、確立された契約（APIドキュメント）、API管理が重要となります。
2. イベント駆動型のアーキテクチャー:IBM MQのようなメッセージ・キューイング・サービスや、オープンソースのApache Kafkaのようなイベント・ストリーミング機能を使って、イベント駆動型のアーキテクチャーを構築することができます。イベント・ドリブン・アーキテクチャーでは、ミドル・インテグレーション・レイヤーを形成するキューを利用することで、入力されるアプリケーション・トランザクションがデータベースの制約により失われないようにします。これにより、より優れたユーザー・エクスペリエンスを提供することができます。イベント駆動型アーキテクチャーとイベント・ストリーミングの違いについてはこちらのブログ(英文) をご覧ください。
3. データ転送: オンプレミスからクラウドへのデータの同期には、コストと時間がかかるため、高速なデータ転送が重要です。また、データを転送した後は、クラウド・ネイティブ・アプリケーションからデータにアクセスできなければなりません。

統合時の課題点

最近では、開発と運用は非常に密接な関係にあります。これが、「DevOps」という言葉が一般的になった理由の一つです。ひとつのチームの中で、開発者は開発中心の仕事をするだけでなく、それぞれのアプリケーション開発領域に関連した運用中心の仕事もしています。そして、複数の環境で複数の仕事をしている人たちがいると、運用コストが上がります。例を挙げてみましょう。

例えば、全国に2,000ヶ所のデータ配送センターを持ち、米国西海岸と米国東海岸に2つのクラウド・データセンターのハブを持つ倉庫配送サービス会社で働いているとします。

各データ配送センターでは、Kubernetesクラスターをローカルに稼働させて、倉庫にある在庫と利用可能な在庫を把握しているとしましょう。つまり、2,000ヶ所の配送センターには、少なくとも2,000のKubernetesクラスターが存在することになります。また、メインのKubernetesクラスターがある2つのハブが、すべてのエッジ環境と通信していることも忘れてはなりません。

ここで、あるアプリの新バージョンを2,000カ所の配送センターすべてに展開する必要があるとします。このシナリオは、オペレーション・チームにとっては大きな課題です。そこで、分散クラウドの出番となるのです。

 

分散クラウドが単一ビューを提供

分散クラウドにより、チームは実際のアプリケーションやコードの開発により集中し、デプロイや運用面をあまり気にしなくて済むようになります。基本的に分散クラウドとは、Kubernetesクラスターがどこで稼働しているかに関わらず、パブリック・クラウドの中心的な場所からすべてを管理できることを意味します。

先ほどの倉庫のシナリオに戻りましょう。運用担当のエンジニアがアプリのアップデートを配信したい場合、分散クラウドの残りの部分を管理している2つのハブのうちの1つに行き、パブリック・クラウドにすべてのエッジ・ロケーションへの配信を任せます。パブリック・クラウドは、これらのエッジ・ロケーションとすべてのクラスターの稼働状況を正確に把握しているため、このように機能します。

1つの企業のすべてのアプリケーションとハイブリッド環境を考慮すると、統合ポートフォリオ全体の一部として非常に多くのソリューションが存在することになり、それ自体が問題となります。時間とコストがかかり、非効率的です。企業が必要としているのは、単一のプラットフォーム、つまり単一のガラスのようなものです。その単一ビューは、分散クラウド・アーキテクチャーに基づいています。

 

分散クラウドによる統合フェーズ

さて、企業がアプリケーションの統合のために異なる機能を持つ多くのテクノロジーを抱えている場合、いわば大量の技術的負債を抱えていることになり、チームはこの複雑さを管理・維持しなければなりません。分散クラウドは、これを大まかに2つのフェーズに分けて対処します。

フェーズ1：プラットフォーム管理の負担からDevOpsを解放する

例えば、パブリックAPIを管理し、レート制限を設け、パブリック・ゲートウェイを設定する方法が必要だとします。オープン・ソース・プロジェクトを手動でセットアップするためにリソースを投資する代わりに、エンタープライズ・ソリューションを利用することにします。 IBM API Connect® であれば、IBM CloudがIBMパブリック・クラウドでサービスとして維持・管理してくれることがわかっているからです。ユーザーとしては、管理するのではなく、単にソフトウェアを使用しているだけですみます。

as-a-serviceの機能を利用することで、開発者は重要なこと、つまりAPIを書いて公開することに集中できるようになります。企業は、労力、時間、コストを節減できます。

Phase 2: 統合するために重要な統合

統合に必要なのは、APIの管理だけではありません。先ほど述べたように、大きく分けて3つあります。API管理、イベント駆動型アーキテクチャー、データ転送です。もちろん、この3つのカテゴリーの下には、さらに小さなサブ・カテゴリーがあります。

これらのカテゴリーに異なるベンダーが存在するということは、複数の環境が存在することを意味し、複雑さを生み出します。真の統合とは、部品の数を減らし、可能な限り統合することで複雑さを軽減することです。例えば、IBM Cloud Pak® for Integrationは、複数のツールをバージョン管理されたパッケージにまとめています。つまり、API管理ツールが、イベント駆動型のアーキテクチャ、メッセージ・キューイング、データ転送サービスとシームレスに動作することがわかっているのです。

プラットフォームに関わらず、統合されたインテグレーションの必要性は非常に重要です。複数のベンダーが提供する複数のツールを使用して複雑な作業を行い、すべてを繋ぎ合わせようとして時間とコストを失うようなことは避けたいものです。目指すべきは、一枚の統合された画面のようなものです。

 

分散クラウドによる統合

分散クラウドは統合にどのように結びつくのでしょうか。複数の環境の運用コストは非常に高く、多くのクラスターがさまざまな場所で稼働しているため、企業はパズルを解くために分散型クラウドの集中管理に注目しています。

同じバージョンのコンテナを複数のエッジ環境で実行している場合、すべての環境に関するデータを取得するための単一の統合された方法が必要です。分散クラウドでは、どのクラスターが稼働しているのか、アプリケーションがどこで正常に動作しているのか、そして最も重要なのは、それらのクラスターのサービス・エンド・ポイントの状態を容易に確認することができます。

IBM Cloud Satelliteは、IBMパブリック・クラウドが提供する分散クラウドです。IBM Cloud Satelliteのような分散クラウドがあれば、単純にクエリを実行して、すべてのエッジ・ロケーションで稼働しているすべてのクラスターのアプリケーション・エンド・ポイントを得ることができます。そうすると、リストが出力されます。

これにより、不必要な統合に時間を費やすことなく、連携が必要なアプリケーションを統合するためのより良い方法が得られます。すべてのエッジ・ロケーションが相互に連携しているわけではありませんが、メイン・ハブと連携する必要があります。IBM Cloud Satelliteを使えば、他の場所で時間を浪費することなく、コミュニケーションをシームレスにすることができます。

重要なことは、複数のベンダーの複数の統合ツールを使用したくないということです。分散クラウドのおかげで、高価で時間のかかる作業は不要になりました。

 

分散クラウド、始めてみませんか

分散クラウドでは、チームはより迅速で容易なヘルス・チェック、シームレスな統合、優れた可視性と信頼性の高い管理を行うことができます。その上、IBM Cloud Satellite のような分散型クラウド・ソリューションは、複数のロケーションにまたがる複数のクラウド・ネイティブ環境を管理する際の全体的な課題や運用コストの削減に役立ちます。これは、すべてのDevOpsチームにとってもありがたいことです。

 

詳しくは:

IBM Cloud Satelliteについてさらに詳しいことは、こちらをご参照いただけますと幸いです。

• IBM 分散クラウドお役立ち情報: こちら
  
• IBM 分散クラウド Cloud Satellite 公式サイト: こちら

 

分散クラウドやIBM Cloud Satelliteに対するご質問やご相談がございましたら、ぜひ公式サイト(こちら)からお寄せください。

---

翻訳：IBM Cloud Blog Japan 編集部

*このブログは、2021/3/17に発行された“How to Eliminate Unnecessary Application Integration”(英語)の抄訳です。