新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

パブリック・クラウドとは

パブリック・クラウドは現代の開発者にとって非常に素晴らしいリソースです。オンデマンドでリソースを調達でき、料金は使った分だけですみます。そのため開発者の効率が上がり、コストを削減できます。ではパブリック・クラウドはどのように構成されているのでしょうか?

alt

今日は例え話から始めることにしましょう。パイを一から作るとします。どこからやりますか?小麦粉もフルーツもご自分で作りますか?現代社会ではある程度の原材料はスーパーマーケットで買うのが一般的ですね。パブリック・クラウドはまさに一種のスーパーマーケットです。

alt

複数のベンダーやソリューションがあり、好みに合ったツールやソリューションを見つけて選ぶことができます。パブリック・クラウドの説明を始めるにあたり、まずはPlatform、Infrastructure、Softwareのas-a-Service、つまりPaaS、IaaS、SaaSについてお話しします。ただしここでは、パブリック・クラウドで利用できる、さまざまなコンピュート・ソリューションにおける全体的な制御と、オーバーヘッドに焦点を当てます。

alt

[全体的な制御とオーバーヘッド]

ベアメタル

このボックスが大きくなると、制御機能が高まりますが、オーバーヘッドも増加します。それでは一番大きいボックスから始めましょう。ここにベアメタルを配置します。ここでは大半のインスタンスを制御できますが、それらを保守するために多大なオーバーヘッドも発生します。

alt

VPC/VMware

1つ上に上がりましょう。ここにはVPCやVMwareがあります。これらのソリューションによってマシンを自動的に起動できるので、オーバーヘッドは少し減ります。

alt

Kubernetes/OpenShift Container Platform

もう1つ上がるとKubernetesやOpenShift Container Platformなどのソリューションがあります。ソリューションでは実際のワーカー・ノードの高度な抽象化が可能です。クラスターを動作させるマシンは基本的にプラットフォームで管理されるので、ユーザーはコンテナーの記述に集中できます。

alt

Cloud Foundry/Cloud Functions

さらに上に行くとCloud FoundryやCloud Functionsがあります。これによって開発者はコードのみに集中し、ネットワーキングやスケーリングなどの処理はプラットフォームに任せることができます。

alt

一連のコンピュート機能が揃いましたが、パブリック・クラウドの利点はこれだけではありません。必要な機能を実行できる統合やサービスもあります。本日はパブリック・クラウドを採用したサンプル・アプリケーションのアーキテクチャーについて見ていきましょう。

alt

[サンプル・アプリケーションのアーキテクチャー] VMやベアメタルの機能に依存しているレガシー・アプリケーションがあるとします。ここにVPCまたはベアメタルを配置します。この上でコンテナー、もっと正確に言うとマシンを起動させます。

alt

これらのマシン上でレガシーのバックエンド・アプリケーションが動作します。それを3台のマシンにスケール・アウトします。これでバックエンド部分ができました。

alt

これはサンプル・アプリケーションのバックエンドでの計算に使用されます。フロントエンド・アプリケーションで採用するモデルには、フロントエンドと、フロントエンド用のバックエンドがありコンテナーを基盤としています。

alt

先程とは少し違うモデルです。ワーカー・ノードはKubernetesまたはOpenShiftレイヤーで管理されます。

alt

ここがKubernetesまたはOpenShiftレイヤーです。この上にコンテナーをデプロイしていきます。

alt

先に述べたようにフロントエンドとそのフロントエンド・アプリケーション用のバックエンドがあります。それぞれをスケールアウトしてKubernetesまたはOpenShiftで管理します。

alt

これがアプリケーション・アーキテクチャーの基本です。バックエンドとフロントエンドのアプリケーションがあり、そのすべてがコンピュート・ソリューションで実行されます。

alt

[ストレージ]

ではクラウド統合の利点を活用して、その他のいくつかの要件についても構築していきましょう。まずはストレージです。

alt

フロントエンド・アプリケーション

フロントエンド・アプリケーションでは顧客のログイン・データ等を保存するためにSQLデータベースなどが必要になります。ここにあるアプリケーションがSQLデータ・ストアを使用します。

alt

バックエンド・アプリケーション

バックエンド・アプリケーションの要件は少し違います。標準のSQLストアではなくCloud Object Storageが必要です。ここにクラウド・オブジェクト・ストア・インスタンスを配置します。これをバックエンド・アプリケーションが使用します。ストレージについては以上です。

alt

[DevOpsとツール・チェーンの機能]

次はDevOpsとツール・チェーンの機能を見ていきましょう。ここにもパブリック・クラウドの利点が生かされています。ここに配置したKubernetesアプリケーションで使用するために、コードは2つのリポジトリーに分割されます。

alt

ツール・チェーン機能

1つは実際のコンテナーとアプリケーション用のコード。もう1つはインフラストラクチャー用のコードです。インフラストラクチャーもコードとして管理したいからです。ここでツール・チェーン機能を利用します。

alt

このアプリケーションはツール・チェーンを利用して、コンテナーをデプロイします。

alt

Terraform

インフラストラクチャーでも同様のツール・チェーンを使用しますが、この場合はTerraformを使います。これはインフラストラクチャーをコードとして管理するオープンソースのツールです。

alt

ここではTerraformがワーカー・ノードの動作や、Kubernetesレイヤーを管理します。

alt

ここまではクラウドのストレージとDevOpsについて説明しました。次はツール用のセントラル・ロギングまたはモニタリング・ソリューションについて見ていきましょう。

alt

[セントラル・ロギング]

ここにあるバックエンド・アプリケーションと、フロントエンド・アプリケーションの両方からセントラル・ロギング・ストアにデータを送信します。

alt

ロギング・サービス

ここに描いたのがロギング・サービスです。これはKubernetesで実行されるアプリケーションだけでなくVMware、ベアメタルまたはVPCで実行されるバックエンド・アプリケーションの主要なログ・ソースとなります。

alt

[ネットワーキングとセキュリティー]

セントラル・ロギングについては以上です。次に利用するサービスはネットワーキングとセキュリティーです。このサンプル・アーキテクチャーのバックエンド部分にはプライベートなデータが保存されています。このためバックエンドへはプライベート・エンドポイントからのみアクセスするようにしなければなりません。

alt

フロントエンドについてはそこまでの注意は必要なく、パブリック・エンドポイントからアクセスできます。このように2分割すると、こちら側は完全にプライベートで、プライベート・エンドポイント専用です。こちら側でパブリック・エンドポイントからデータにアクセスできます。

alt

データが保護されていないわけではありません。独自のキーを使用して、証明書やキーでデータを保護することができます。

alt

両方の環境がセキュリティーで全面的に保護されます。ではこのように分割した場合、フロントエンド・アプリケーションは、バックエンド機能とどのように通信するのでしょうか。

alt

ここでもクラウドを利用します。この場合はVPNゲートウェイなどを利用します。

alt

このようにゲートウェイを設置すると、フロントエンドとバックエンドの相互通信が可能になります。

alt

今回ご紹介したのは、パブリック・クラウドの機能のほんの一部にすぎません。人工知能、機械学習、データ・アナリティクス、洞察、一般的なパブリック・クラウドで利用できる多数のサービスについてはまだお話ししていません。

alt

パブリック・クラウドの概要をご覧いただきありがとうございました。 無料のIBM Cloudアカウントに登録すれば、費用をかけずにいつでもクラウドで作業を開始できます。