今はゼロからアーキテクチャを考える時代ではない
三宅和之氏：それでは、私からは「Well-Architected Frameworkを活用したAzure設計パターン」というテーマで、お話しします。お願いします。
まず自己紹介をします。三宅といいます。株式会社ゼンアーキテクツという会社をやっています。個人的には、Microsoft MVPをAzure部門でいただいています。それ以外にもVue.jsの日本ユーザーグループの運営を手伝ったり、ブログを書いたり、いろいろとコミュニティ活動もやっています。
ゼンアーキテクツという会社は、オルターブースさんと同じように、Azureの技術支援や導入支援をやっていて、オルターブースさんとは、よく一緒に仕事もしています。今日もこういった場にお招きいただいて、大変光栄です。
では、内容にいきたいと思います。今日はMicrosoft AzureのWell-Architected Frameworkの内容を、私なりに解釈した観点で紹介したいと思っています。大きく2つの観点ですね。
聞いたことない方もいると思うので、簡単にこのWell-Architected Frameworkを紹介します。
このアーキテクチャの話をするときに、クラウド時代になる前と後ではぜんぜん前提が変わっているという話は、やっぱり避けて通れないと思うんですね。
「従来」って書きましたが、今となってはもうこれは10年くらい前の話です。10年以上前の話を「従来」って書いていますが、オンプレミス前提のアーキテクチャの設計はどうしてもフルカスタマイズになる傾向があって、ちょっと言い方は悪いですが、オレオレアーキテクチャになります。それが悪いとかではなくて、当時はそれしかできなかったんです。
今はAzureみたいなパブリッククラウドを前提として、アーキテクチャを設計するというアプローチになってきているので、アーキテクチャ自体も、イチからオレオレアーキテクチャを組み立てるんじゃなくて、パターンやフレームワークをいかに効率的に利用して組み立てていくかです。
言い方を変えると、今はゼロからアーキテクチャを考える時代じゃないんですよね。だから、車輪の再発明を防止する効果もあるし、Azureが出てから10年も経っているので、けっこう実証済みの実績のあるプラクティスが出てきているんですね。なので、そういったものを流用しながら効率的に作っていける時代になってきました。
AzureのWell-Architected Frameworkが必要になった背景と狙い
AzureのWell-Architected Frameworkというものも、1～2年くらい前に、出てきていて。実はAWSにもこういったフレームワークがあって、別にAzureだけのものではないんですけれども。
いろいろと定義があって、マイクロソフトの公式ページにもドキュメントがあります。全部読もうとするとものすごい量なので、今日は本当に簡単に、自分の解釈で説明します。いわゆる非機能要件に近い観点を、Well-Architected Frameworkの5つの観点に分類して、アーキテクチャをどういう観点から設計すべきか、ベストプラクティスはどういう観点なのかを整理したものです。なので、これをやれば絶対うまくいくではなくて、1つの指針や指標を5つの観点に分割して提供しています。
ただ、それじゃわかりにくいですよね。なので、私はこういう解釈をしています。フレームワークが必要になった背景は、最初にお話ししたように、時代が変わって、自前で作る箇所って減ってきていることなんですよね。けれども、ベストプラクティスもものすごい量なので、「じゃあ、ベストプラクティスって何を使ったらいいの？」っていう疑問が出てきます。
集めるのも大変だし、選んでいくのも大変。「信頼性だったらどういうものを使う？ セキュリティだったらどういう考え？」と「それぞれの軸に分けて整理するとわかりやすくなるよね」というのがAzure Well-Architected Frameworkが登場した背景です。
真の狙いはどこにも書いていなくて、私の勝手な思いですが、機能要件と合わせて非機能要件をインプットとした設計ってクラウドじゃないオンプレミスの時代もやっていたと思うんですが、そのときにどうやったらこの非機能要件を実現できるのか。
例えば「99.9パーセントを達成しなさい」みたいなSLAがあって、「それをどうやって実現するの？」っていうときに、「今までと違って、いちいち個別のシステムで、ゼロから実現策を考えなくてもいいですよ。こういうやり方やれば達成できるようにクラウド自体は作っているので、選んでください。レベルを自分で定義してください」という狙いがあるんじゃないかなと思っています。
5つの観点「セキュリティ」「信頼性」「コスト効率化」「パフォーマンス効率」「オペレーショナルエクセレンス」
簡単に5つのカテゴリー見ていきたいと思います。Well-Architected Frameworkは5つカテゴリーがあって、こういったセッションの場で話す場合、必ず5つを順番に話さなきゃいけないので、時間がなくなるんですね。なので、ちょっと強弱をつけていきます。私が実際設計して、気にする順番を勝手に順位づけして説明するので、後ろのほうはもしかしたら資料を紹介するだけになるかもしれないです。そこだけ事前にお断りしておきます。
セキュリティ・信頼性・コスト効率化・パフォーマンス効率・オペレーショナルエクセレンスという5つの観点があって、それぞれにいろいろなテーマがちりばめられています。実際のアーキテクチャの設計現場でよく使うテーマを切り出して、Azureで言うとどういったサービスで実現しやすいのかを紹介したいと思います。
パフォーマンス効率のテーマ スケーリングと最適化
まずパフォーマンス効率からいきます。私が最初にこれを持ってきたのは、やはりアーキテクチャ設計を行う上では「パフォーマンス効率をよくするための設計」がクラウドならではの一番のテーマですし、オンプレミス時代と手法がぜんぜん違って、かつ、非常に影響範囲が大きいからです。パフォーマンス効率もいろいろなテーマがあるんですが、スケーリングとパフォーマンスの最適化、この2つは特にいつも気を遣って設計しています。
このパフォーマンス効率の観点でAzureに対応するサービスって、はっきり言ってほぼ全部なんですよ。けれども、その中で「パフォーマンス効率の中でも、こういったテーマであるとこのへんのサービスをよく使いますよ」という観点でいくつかピックアップしてきたので、紹介します。
まずスケーリングですね。スケーリングっていくつか観点あるんですが、クラウドでよく出てくるのが、オートスケール、つまり自動スケールという考え方です。これなんかはクラウドならではのテーマというか、できるようになったことですよね。
ここにApp ServiceやAzure Functionsなどサーバーレス系のサービスを置いていますが、こういったサービスを使うと事前設計がいらないんですよ。
自動スケールは、全部このプラットフォーム側に組み込まれているので、あとはコストやどういうときにスケールさせたいかをプロジェクトごとに合わせて設定をするだけでできます。自動スケールが求められるような非機能要件のシステムの場合は、制約がないのであれば、こういったサーバーレス系のサービスをWebのフロントやバックエンドの処理に持ってくると、それほど苦労せずできます。
それからスケールアップとスケールアウト。縦方向・横方向みたく、水平方向・垂直方向という言い方をするんですが、場面やサービスによって使い分けをしなければならないです。ただし、スケールアップは考え方が簡単で、これもオンプレミスの時代のCPUにコア数やメモリを増やすという話ですね。
けれども、クラウドだからスケールアウトがいかにできるか・させられるかというところの設計の工夫がポイントになってきます。
Azure FunctionsやApp ServiceやCosmos DBなどのサービスもスケールアウト型を利用できます。それらを使うような設計にすると、よりパブリッククラウドのいいところを引き出せるので、そういったところを考慮してスケーリングを設計していくといいと思います。
パフォーマンス最適化という意味では、いろいろいろな観点の最適化があるんですが、ここではネットワークとストレージというテーマでお話ししようと思います。
ここで言いたいのは、なんでもかんでも受け入れた要求を同期的に処理しなきゃいけないのかというと、実はシステムをバラバラに考えると、必ずしも同期的に処理しなきゃいけないものではないんですよね。
要求を分類して、順次処理ができるものはバッファリングします。、ここにアイコンで出しているようにEvent HubsやStorage Queueを使って、一度ためて、バックグラウンドで順次処理させてシステム全体の負荷を下げるという戦略をよく使います。
それからデータベースは、Cosmos DBのパーティション機能みたいな、パーティション分割というまさに水平スケールをするための技術なんですね。なので、パーティション分割をこういう単位でして、このシステムはスケールするよ、拡張性を持てるようにするよと設計するのがパフォーマンス最適化の、一番悩ましいけれども効果が非常に大きい点ですね。
これ以外にも、パフォーマンス効率には考えなきゃいけないことがいっぱいあるのですが、今日はこの2点をあえて紹介します。Well-Architected Frameworkと関連するんですが、その中には入っていない数十個のクラウド設計パターンがドキュメントにもいっぱいあります。
今日は紹介できませんが、のちほどドキュメントをアップロードするので、そこから「パフォーマンス効率に関連するキューベースの負荷平準化パターン」っていうものがあるのかと紐づけて見てもらえば、イメージが湧きやすいと思います。
パターンだけいきなりイチから順番に見ていっても、なにも頭に入ってこないので、パフォーマンス系なのかセキュリティ系なのか、そういった観点をもってドキュメントに入っていくと非常にわかりやすいです。その入口を作るのが、Well-Architected Frameworkなので、そういう使い方をしてもらうといいと思います。
RPOとRTOの短縮で信頼性を向上させる
じゃあ2番目にいきましょう。信頼性ですね。これは大きく言うと、高可用性や、障害が起きたあとの復旧の話ですね。大きくこの2つに分けられます。
Azureと、その他いろいろいろなサービスが信頼性の機能を持っています。ここにはSQL DatabaseやAzure StorageやApp Gatewayのアイコンを持ってきていますが、もちろんこれだけが対応しているわけではなくて、いろいろとあります。今日は実務の観点からよく使う戦略、高可用性とセットでよく使うという観点で、この2つを紹介します。
まずクラスタリングです。オンプレミスの時代から、普通にデータベースである場合は、信頼性を上げるときにクラスタリングをやっていましたよね。これも同じように、RDBの代表例であるSQL Databaseにはフェイルオーバーグループというクラスタリング機能があります。設定次第ですが、例えばここの図にあるように、東日本のデータセンターで大きな障害が起きてどうしようもなくなったときに、自動的に西日本のデータセンターにフェイルオーバーする機能です。
ほかにも、自分でモニターをして、データセンター自体は問題なくても、システムの負荷やアクセスのされ方によって、西日本に振り分けたり、同時に利用するようにActive/Active構成にしたり、こういうことを自分でコントロールできるので、このあたりを使うことを頭に入れておいてもらえればなと思います。ほかのデータベースでも、もちろんこういったものがそれぞれ設定されていますが、SQL Databaseでは非常に枯れた機能で、普通に使えます。
それから、ネットワークも負荷分散が必要です。入口のところで負荷分散をさせるような設計にすると、もちろん負荷が分散されるメリットがあるんですが、これは実は信頼性の向上にもメリットがあるんですよね。
アプリケーションバックエンドに、例えばApp ServiceみたいなWebサーバーを数台用意しておいて、どこかで障害が起きてもApplication GatewayやFront Doorからは自動的に飛ばないようにきちんと制御してくれます。そういった意味では、信頼性を上げる技術として、この負荷分散は実は使えます。
もちろんパフォーマンス面でも分散させるという意味での役割をもつんです が、信頼性を上げるという戦略でも出てくるので、このApplication Gatewayや、最近ではFront Doorですね。こっちを私の会社ではよく使うんですが、どちらも似たような役割をもっているので、このあたりも信頼性向上に役立つことを紐づけてもらえれば、イメージしやすいんじゃないかなと思います。
それから、どうしてもクラウドの場合は「100パーセント絶対に障害が起きませんよ」ということは無理なので、そこはなにかしら障害が起きたときに、復旧をどのレベルでするのかを、事前に与えられた非機能要件をベースに設計に織り込んでいく必要があります。
そのときに指標として、これもオンプレミスの時代から言われていますが、RPO（Recovery Point Objective）・RTO（Recovery Time Objective）、これらをそれぞれ短縮していくのが目標になってきます。これもコストと労力のトレードオフと昔から言われていたんですが、ここに書いているサービスであれば、RPO短縮とRTO短縮のための仕組みがもともと用意されているので、あとはもうコストと相談して、事前に設定を入れておくか選択するだけでできるようになっています。
私はオンプレミスのシステムの時代に、こういったものに取り組むためにいろいろいろな仕掛けを作ったのを覚えていますが、今はクラウドのポータルでゲージをグーッとずらすだけで、実現できる時代になったので、非常に効率よく設計に織り込めるようになったなと思って重宝しています。
信頼性についてはほかにもいろいろと観点あるので、ぜひドキュメントを見てみてください。
（後半へつづく）
