Azure PaaS Overview

  • Article

はじめに

非常に変化の速いクラウドの世界ですが、その中でも Microsoft Azure において PaaS : Platform as a Service に位置づけられるサービス群はバリエーションが豊富で、情報をキャッチアップしていくことは困難です。ともすれば情報の量と変化の多さに辟易して敬遠してしまいがちです。このため本記事では Azure における個々のサービスの紹介は省き、一般論としての PaaS の意義と価値を改めて整理し、読者の方が評価や導入されるにあたって基本として押さえておいて頂きたい考え方についてご紹介したいと思います。

  •  Microsoft Azure における PaaS
  • PaaS の意義と価値
  • 開発標準とプラットフォーム

Microsoft Azure における PaaS

Microsoft Azure にはたくさんのサービスがありますが、以下の図中の赤枠の中のサービス群が PaaS として分類されます。どれが PaaS でどれが PaaS ではないのかといった分類上の議論にあまり意味は無いと思いますが、そもそも何故こんなにたくさんのあるのでしょうか？ この中から適切なものだけを選択して組み合わせてアーキテクチャを構築するというのは考えるだけでも頭の痛い作業です。そんな大変な思いをしてまで PaaS を利用する必要があるのでしょうか。

paas-of-azure

しかし Azure のドキュメント「PaaS とは」において、主に開発生産性の向上がその利点として掲げられています。また Forester 社の調査「Microsoft Azure PaaS の経済的な影響全般」においても費用削減等のビジネス上の便益が語られています。本記事においても改めて PaaS とはどういうものなのか、それを利用するメリットとは何なのか、利用する上での考慮事項等についてご紹介したいと思います。

PaaS の意義と価値

さて NIST の定義では、、、というのは置いておいて、IaaS や SaaS、オンプレミス との対比として、システムの構成要素をユーザー様とマイクロソフトの責任領域で分類した図がよく用いられます。物理的なネットワーク、ストレージ、サーバー、仮想化のレイヤが提供されるという意味では IaaS と同等です。それに加えてクラウドベンダーは一般的に求められる各種のアプリケーション特性を加味し、OS、ミドルウェア、ランタイム までをセットで提供することでユーザー様からの需要に答えていきます。この需要が多種多様であるため、先ほどのように数えるのも嫌になるほど多くのサービスがラインナップされることになってしまうわけです。

service-stack-and-responsibility

この区分は、非常に大まかに言ってしまえば機能要件と非機能要件を司るレイヤであるとも言えます。非機能要件領域に対して各サービスは基本的な機能に加え、ユーザー様が”設定”することのできるいくつかのオプション機能も提供します。これらの機能やその組み合わせはマイクロソフトが責任を持ってテスト済みのものになります。社内でのテストだけではなく、プレビュー期間から多数のユーザー様にお試しいただくことで実績を積み、品質を向上したうえで一般公開されるわけですから、比較的新しい機能であっても実績があることになります。このことを根拠としてユーザー様はインフラストラクチャに対する設計・構築・テストのコストを削減することができることになります。そしてアプリケーションの本質的な目的である機能要件、すなわちビジネス価値の実現に注力できるわけです。

組み込み済みの品質

非機能要件は XXXability と呼ばれるような品質特性に対して定義されることが一般的であると思います。各サービスにおいてはこれらの品質特性に対する一定のソリューションが用意されていますので、ユーザー様はサービスを利用するだけでこれらの特性を（全てでは無いにしても）活用できることになります。以下では Azure における PaaS の代表格とも言える Web Apps を例として、各品質特性の観点から見てどのようなソリューションが提供されているかを見ていきたいと思います。

拡張性 : Scalability

Web Apps においてアプリケーションは App Service Plan と呼ばれるサーバーファーム上で動作します。App Service Plan に対してサーバースペック（コア数、メモリ量等）やその台数を調節することで、スケールアップ／スケールアウトを柔軟に行うことが可能です。

安全性 : Security

Web Apps にアクセスするユーザーの認証および承認に対しては、Azure Active Directory を使用したオンプレミス ID を使用することもできますし、 Microsoft アカウント、Google、Facebook、Twitter といったソーシャル ID を使用することもできます。また既定で付与されるドメイン名 *.azurewebsite.net では HTTPS が有効になっており暗号化通信が可能ですし、カスタムドメイン名に対する証明書を購入あるいは持ち込んで HTTPS を有効にすることも可能です。App Service 環境を使用した場合には Web Apps を IaaS 仮想マシンと同様に Azure 仮想ネットワーク上に配置することが可能です。これによりパブリックインターネットからのアクセス経路を排除する、あるいは、Web アプリケーションファイウォールを設置するといったような、より高度なセキュリティオプションを組み焦ることも可能になります。

耐障害性 : Fault Tolerance

アプリケーションやコンテンツは各 Web サーバーのローカルストレージではなく、App Service Plan で共有されるストレージに配置されます。この共有ストレージは他のストレージサービスと同様に多重化されていますので、もし Web Apps をホストするサーバーが破損したとしても、そのデータが失われる可能性が極めて低くなるように構成されています。

可用性 : Availability

ユーザーからのリクエストは Azure の Load Balancer から負荷分散されて Web サーバーに転送されるように構成されています。各 Web サーバーは Azure によって常にその正常性が監視されておりますので、何か異常があれば別の Web サーバーが自動的にアサインされ、負荷分散が切り替わることで可用性を実現しています。またアプリの複製機能を用いて別のリージョンに同じアプリを配置し、Traffic Manager サービスを組み合わせることで、広域災害にも耐えうる高可用性を手に入れることもできます。

運用容易性 : Operability

Azure の診断機能を使用することで、Web サーバーの各種ログやアプリケーションログを取得することができます。ログはファイルシステムに出力した場合は FTP で、Blob や Table ストレージに出力した場合は REST API で取得することが可能です。また Application Insight を組み合わせて使用することで性能や稼働状況といった各種のテレメトリを収集・分析し、何か問題があればアラートを上げるといった自動化も可能です。

保守容易性 : Maintainability

Web Apps にアプリを配置するには、伝統的な FTP(S)、OneDrive や Dropbox との同期、Visual Studio Team Services、GitHub、BitBucket からの継続的デプロイ、ローカル Git からの Push といった様々なオプションが提供されているため、容易に動作環境を構築し、テストを行うことが可能です。またステージング環境を作成してアプリを配置しておき、最終的な品質確認が完了した後に運用環境とスワップすることで、ダウンタイムなしで最新のアプリへアップデートすることが可能です。

移植性 : Portability

Web Apps の Web サーバーは Azure 特有の実行環境ではなく、 Windows IIS の ARR モジュールと、その背後で動く ASP.NET 、Node.js、PHP、Tomcat、Jetty といったアプリケーションサーバーで構成されています。これらのコンポーネントは入手が容易ですので、他社クラウドやオンプレミス環境上に同等の動作環境を構築することは技術的に可能です。つまり Web Apps 向けに開発したアプリは Azure に囲い込まれるリスクがありません。また現在開発中の Azure Stack がリリースされれば、Web Apps に限らず Azure そのものの互換環境を構築することも将来的には可能になってくるでしょう。

相互運用容易性 : Interoperability

Web Apps は既定でインターネット上の各種サービスと HTTP(S) を使用した連携が可能ですので、Web API を利用する、あるいは提供することができる環境になっています。独自に実装せずとも Logic Apps で提供されたコネクタを利用することで、コーディングレスで外部システムと連携することも可能です。またハイブリット接続、VNET統合、App Service 環境といった、 Azure IaaS 上の仮想マシンやオンプレミス環境でホストされたサーバーと連携するためのオプションも提供されています。

低コスト・高品質を迅速に実現

上記から Web Apps が単なる「IIS が有効になった Windows サーバーを並べただけのモノ」ではなく、これだけの品質を実現するために内部的には様々なものがセットアップされており、その料金に含まれる形で提供されていることがご理解いただけるかと思います。これ以外の PaaS でも、必ずしも全てでは無いにしても、一定の品質が標準機能として提供されています。これらは既定で有効になっているか、Azure ポータル、PowerShell、ARM テンプレートによって“構成”するだけで有効にすることができます。

一方オンプレミス環境や IaaS であれば前述のような品質は独自に作り込む必要があります。サーバー、ストレージ、ネットワーク、OS、ミドルウェア、ランタイムを選択し、組み合わせ、製品固有の設定方法を駆使してカスタマイズし、期待した品質レベルに到達しているかをテストによって検証していく必要があるわけです。
PaaS の価値を最大限に生かすための知識はもちろん必要になりますが、その構築に必要となる工数と時間は、システム全体に要するそれに対して非常に小さな範囲で収まるのではないでしょうか。

開発標準とプラットフォーム

この考え方やアプローチ自体は決して新しいものではありません。従来からも成果物品質の底上げや開発生産性の向上という課題に対して、標準化、フレームワーク、共通部品、アーキテクチャといった形でアプリケーション開発やプラットフォームに一定の制約とルールを定義する、というソリューションは一般的だったかと思います。Microsoft Azure における PaaS とは、マイクロソフト社がアプリケーション開発における一般的な課題に対して、自社のノウハウを元に編み出したソリューションである、と言うことができるかと思います。

paas-category

PaaS を使いこなすうえでは、どのサービスがどういった需要に答え、どのような品質特性をそなえているものなのかを理解し、適切に取捨選択することが必要です。当然ながらクラウドベンダー視点で全体最適化されたソリューションが、開発者の皆さんが実現すべき個々の“要件”に対して必ずしも適切であるとは限りません。というよりも完全に一致する方が稀でしょう。となれば選択肢は 3 つです。

  • IaaS を利用してフルカスタマイズで構築する
  • 問題となる部分だけ IaaS を組み合わせて構成する
  • 既存の PaaS で妥協する

どれも間違った選択ではありません。ただ PaaS ではなく IaaS を部分的に、あるいは全体的に利用するということは、設計や構築における自由度を得る代わりに、PaaS が提供する価値を捨てることでもあります。逆に言えば既存の PaaS で“妥協”することできれば、これまで紹介してきた価値は即座に、そして多くの場合はより安価に手に入るものであると考えます。

おわりに

PaaS の価値を明確にしようとするあまり、若干 IaaS を貶めるような論調の記事になってしまいましたが、IaaS は IaaS でその価値は大きなものです。PaaS における生産性と IaaS における自由度の問題はあくまでもトレードオフの関係であることを忘れないでください。ただ Azure の導入をご検討いただいているお客様とお話をしていると、従来と同じであることに固執するあまり、本来の“要件”を見失ってしまっているケースが散見されます。今後クラウドアプリケーションを構築される際には、従来からの“方法”ではなく、本質的な“要件”を見定め、PaaS で楽をすることが出来ないか、IaaS の自由度が本当に必要なのか、是非ご一考いたけだければ幸いです。