CLOSE

Well-Architected Framework を活用した Azure 設計パターン(全2記事)

車輪の再発明はもう必要ない Well-Architected Frameworkがアーキテクチャ設計を爆速にする

日本マイクロソフトとオルターブースが、Azureを利用したクラウドアーキテクチャおよびアプリケーションアーキテクチャの設計を検討する際に必要な知識やスキルについて発表しました。ゼンアーキテクツCTOの三宅和之氏はWell-Architected Frameworkを活用したAzure設計について話しました。全2記事。後半は、Well-Architected Frameworkにおける「オペレーショナルエクセレンス」「セキュリティ」「コスト最適化」について。前半はこちらから。

入れない理由が見当たらないCI/CD

三宅和之氏(以下、三宅):3つ目です。これも私が大好きな分野で、DevOpsの分野と同じところをWell-Architected Frameworkでは「オペレーショナルエクセレンス」というカテゴリでまとめています。大きくDevOpsと、それからモニタリングですね。そういった分野のことがベストプラクティスが書かれています。

左側がDevOps系。さっき松村さんはAzure Pipelinesの紹介されていましたが、GitHub Actionsも似たような役割をもっているので、最近は私の会社でもGitHub Actionsを使うことが多くなっています。

DevOpsはさっき出てきたCI/CD、それから下に書いているこのInfrastructure as Code。インフラもコード化して、全部自動的にデプロイできるようにしましょうという考え方は、個人的にはこの分野に関して、オススメを超えて必須だと思っています。

入れない理由はないですね。入れない理由を今もし何か並べられる方がいたら、24時間でも48時間でも議論してみたいなって思うぐらい、これに関してはメリットしかないです。

効率で言ってもそうですが、プロジェクト全体にガバナンスやセキュリティ観点を導入できます。そういった意味でも、CI/CDは入れない理由がないので、オペレーショナルエクセレンスの中でも一番重要な要素として出てきています。

Application InsightsやAzure Monitorでモニタリングはほぼ十分

もう1つ、いわゆる運用観点で大切になってくるのがモニタリングです。モニタリングに関しては、ただ監視するというより、「どこを監視しますか?」というところなんですよね。監視ってやっぱりいろいろな観点があって、大きく言うとアプリケーションそのものと、それを支えるプラットフォーム・インフラストラクチャ。大きくはその2つだと思うんですね。

それぞれをAzureで言うと、アプリケーション部分はApplication Insightsがカバーしていて、下回りはAzure Monitorがカバーしています。いろいろとほかにもあるんですが、大きくこの2つが役割分担をしています。これらが最近、どんどん洗練されていて、もうほとんどカスタマイズいらずで十分なレベルの監視はしてくれます。

Azureを使っている場合、Azureのサポート契約をして、何か問題や障害が起きたときにサービスリクエストをマイクロソフトに送って「何かここがおかしいんだけど、見てもらえませんか?」ってよく言うんですが、最近Application InsightsやAzure Monitorが、非常に詳しい情報をタイムリーに出してくれるので、よくよく考えたら、この1年、私、SRをほとんど上げていないんですよ。

それぐらい変わってきているなと思うので、Azureを使う方は、まずは余計なことをせずに、Application InsightsやAzure Monitor、このあたりをフル活用していくアプローチでやってみてください。それでほぼ十分なはずです。実際運用していて、ほぼ断言できます。

モニタリング、オペレーショナルエクセレンス。あと2つセキュリティとコストですね。

IDはもう自分で作り込む必要はない

セキュリティですね。これを語りだすと1日でも2日でも1週間でも1ヶ月でもお話できる分野です。なので、あまり詳しくは説明しません。ここにあるとおり、セキュリティといっても多層防御と言われていて、7つぐらい分野が出ていますが、それぞれぜんぜん違う観点で、いろいろいろな対策を入れてなきゃいけないので、ここで話せるわけがないんですね。

とは言っても、いくつかだけ紹介します。特にID関係。私はデベロッパーなので、開発に直接関連するところがすごく気になるんですよ。なので、IDとネットワークについては知っておくといいポイントをいくつか紹介します。

まずIDに関してです。AzureにはAzure Active Directoryという強力なID管理の仕組みがありますよね。ここには書いていないですが、Azure Active Directory B2Cというものもあって、マイクロソフト的にはたぶん仲間なんですが、仲間のようで実は位置づけがぜんぜん違います。

Azure Active Directoryは、どちらかというとだいたい社内システムや組織内の認証に使います。一方、Azure Active Directory B2Cは一般的な、本当にB2Cという名前のとおり、一般ユーザー向けのアプリケーションの認証に使えます。

それぞれシングルサインオンやMFAなど、自分で作り込もうとすると、とてつもなくコストもかかるし難しいものを、設定してちょっとコストをかけるだけで実現できます。

ここで言いたいのは、IDに関してはここ数年、自分で作り込むことを本当にオススメしていないということです。なので、AADじゃなくてほかのプロバイダでもいいですが、自分で作り込むのはできるだけ避けるアーキテクチャ設計を心懸けたいなと思ってやっています。

Private Linkで使えるアプリケーションが増えたPaaSとサーバーレス

それからネットワークセキュリティをあえて出してきたのは理由があります。実は自分のブログ名が「PaaSがかりの部屋」というくらいPaaS・サーバーレスが好きですし、推しているんですが、ネットワークセキュリティという観点で言うと、今までサーバーレスとPaaSは若干相性悪いところがあったんですよ。

ただし、2020年ぐらいからAzureでは、Private Linkという技術でVirtual NetworkとPaaS群を統合して、それぞれのいいところを使える仕組みができました。

そこから設計の幅が非常に広がって、今までPaaSを使うのはセキュリティ観点で躊躇していた会社も「これだったら問題ないよね」という事例が多くなっていて、PaaSとサーバーレスがより広範囲なアプリケーションで使えるようになってきたというのが、この1~2年でAzureが大きく変わってきた点なのかなと思っています。

セキュリティは幅広いので、ぜひドキュメントを読んでみてください。

コストの最適化とコストの監視

最後にコスト観点ですね。実はコストを切り出して語ることってあんまりなくて、今までお話しした4つのテーマ、セキュリティや信頼性やパフォーマンス効率など、これらをどのレベルにもっていくかというときに、必ずコストの観点って必要になるんですよ。なので、コストだけで何かを考えるということはない。ほかの観点とトレードオフを考えるときに使うものなんですね。

ただ、2つほどピックアップしてきたのが、PaaS・サーバーレスに代表されるマネージドサービスや従量課金モデル……サーバーレスは特に従量課金モデルですよね。これらが使えるのであれば使ったほうがいいです。

もし使えない理由があれば、そこで初めて外して、最初はなるべくマネージドサービス、従量課金モデルの利用から入るべきです。結局クラウドの最大のメリットって使った分だけ課金されるということですから。これが使いたいと思うもともとの動機の大きな要素です。ここを避けていきなり「じゃあ部品を立てるところから始めましょう」みたいな事例が非常に多いですが、まずそこを忘れずに、クラウドに入ってきてもらいたいなと個人的には強く思います。

あとはコストの監視です。コストもやっぱり監視・分析が必要で、これらが数字でリアルタイムに細かく見れるようになっているんですね。実はこれが満足できるレベルになったのは、ここ1~2年なんですが、今はとても細かくコストを分析・表示ができるようになっているので、管理者は安心してクラウドのコスト面での運用監視ができるようになっているというのを1つ付け加えておきます。

Well-Architected Frameworkはカタログやリファレンスとして使うのがベスト

ということで、なんとか5つ全部終わったので、まとめに入りたいと思います。

Well-Architected Frameworkってちょっと学問的な文章になっていて、それをイチから教科書的に学んでいこうというのは、そういうのが得意な方はどうぞなんですが、実務的にそれが役立つかというと、個人的には直接役立つとはあまり思えないので、例えば非機能要件観点で何かアーキテクチャ設計をするときや、「今からセキュリティの話をしよう」というときに、カタログ的にWell-Architected Frameworkのセキュリティのところを見ながらみんなで検討するだとか、そういったリファレンスとして使うのが一番いいんじゃないかなと思います。

そのときに、この資料でも紐づけしたように、例えばセキュリティであればAzure Active Directoryが出てくるように、組み合わせのよく出てくるパターンがいくつかあるので、そのへんをイメージしてAzureの具体的なサービスと紐づけながら設計していくと、よりイメージがしやすいと思います。

あとは、いくつか紹介しましたが、クラウドアーキテクチャ設計パターンですね。このあたりも活用すると、ほぼ車輪の再発明をすることなく、アーキテクチャの設計を効率よくできるんじゃないかなと思っていますし、私も今は実際それでやっています。

アーキテクチャの設計は昔だと1~3ヶ月ぐらいかかったものが、最近だと早いときは3日である程度決められます。長くても1ヶ月です。これぐらいで決められるようになったのも、やっぱりこのパターンがあるからだと思っています。

あと、Well-Architected Frameworkに関してはホワイトペーパーも出していて、日本マイクロソフトさんから出ているんですが、実は書いたのは私です。このURLからダウンロードできるので、興味がある方はぜひダウンロードしてみてください。

これで終わりにしたいと思います。ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 1年足らずでエンジニアの生産性が10%改善した、AIツールの全社導入 27年間右肩上がりのサイバーエージェントが成長し続ける秘訣

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!