NEXTSCAPE blog

株式会社ネクストスケープの社員による会社公式ブログです。ネスケラボでは、社員が日頃どのようなことに興味をもっているのか、仕事を通してどのような面白いことに取り組んでいるのかなど、会社や技術に関する情報をマイペースに紹介しています。

MENU

de:code「コンサルティングの現場から見えてきた Azure IaaS インフラ設計の最新ベストプラクティス」セッションレポート

先月5月の26日(火)~27日(水)に東京で開催されたMicrosoftの技術コンファレンス「de:code2015」。
4 月末からアメリカで開催された「Build 2015」や「Microsoft Ignite」の情報を凝縮して紹介してもらえる、とのことで大盛況のイベントですが、こちらに行って参りました。

f:id:nextscape_blog:20210909192102p:plain

私はネクストスケープが出展したブースのお手伝いもありましたので全部のセッションを聞くことはできませんでしたが、幾つか為になるセッションを聞くことができました。
今日はそのうちの1つ

「コンサルティングの現場から見えてきた Azure IaaS インフラ設計の最新ベストプラクティス」

をレポートしたいと思います。

 

それでは早速。
27日(水)の朝一発目のセッション、Room Fの

「コンサルティングの現場から見えてきた Azure IaaS インフラ設計の 最新ベストプラクティス」

f:id:nextscape_blog:20210909192143p:plain

ですが、セッション内容は前半がIaaS設計の勘所を理解しましょう、というタイトル通りの内容で、後半は次世代IaaSの新機能の紹介でした。ではまず前半からいきます。

「本当にIaaSが必要か、から考える」


IaaSのベストプラクティス、といいながらまず最初のプラクティスはIaaSは最後の手段でしかない、という話でした。システム設計は次の順番で考えましょうとのことです。

  1. SaaSでできるんじゃないか?(Office365など)
  2. PaaSで作れないか?(Web Appsなど)
  3. どうしても必要な時だけ、IaaSで。

つまり、

SaaS/PaaSはMSのベストプラクティスのかたまりなので、そっちを活用したほうが間違いがない、ということだそうです。IaaSで作れば確かにオンプレライクに構成することができるのでわかりやすいですが、相手はクラウドであってオンプレではないわけです。例えばSLAは99.9%であって100%保証してくれない訳ですから、それに対応した構成をとるとなると、結局クラウドならではの構成をとらなくてはならないわけで、大変面倒です。意外とお金もかかるのです。

それだったら、SaaSとPaaSを組み合わせましょう、ということでした。はい、全面的に賛成です。新規にシステム作るならその考え方を私もお薦めします。でもオンプレからクラウドへ移行する場合はこの限りじゃないです。まずはクラウドで稼働させることが大前提、ということもとても多いですよね。その場合はまずはIaaSで、次のシステム改変時に少しずつSaaS/PaaS化していくことをお薦めします。

「クラウド移行時の鉄則」

続いてその「まずはIaaSでクラウド移行」のお話です。

「こういう要件があるんだけど、Azureでできるの?」という相談がとても多いそうです。でもそれは今までのやり方をそのままやりたいだけであって、要件ではないですよね?例えばクラスタリングできるのか、なんてそれは課題ではなくて解決方法そのものなわけである、とのこと。

だから本当の要件に立ち返って、クラウドならではのやり方で解決していくのが王道のパターンだ、というお話でした。そして、IaaSで悩ましいのがマシンサイズであると。

  • Aシリーズ・・・基本と標準
  • Dシリーズ・・・高速CPUとローカルSSD.DBなどに。
  • Gシリーズ・・・ゴジラ。大容量メモリのモンスターマシン。
  • GSシリーズ・・・Premiumストレージを使った超高級品。

マシンサイズを考える時には異なるシリーズ間での比較を慎重に実施することが大事だそうです。例えば、Aシリーズの方が絶対安いわけではないと。Dシリーズの方がコアが少なくても、メモリが同じだったりするわけだから、とのことです。確かにそうですね。
また、コアとメモリとどちらに重点を置くかで、安くできることがある、とのお話がありました。例えば、A2とD1はメモリが同じですが、D1の方がコアは少ないが、CPUの性能が良かったりするわけです。

そしてAシリーズのBasic(基本)を積極的に活用するべきである、ということでした。スケールがいらない、負荷分散いらないなら、AシリーズのBasicをぜひ、とのことです。なんたって安いですからね。

「ストレージ」

  • 課金

定義サイズではなく、消費サイズベースでの課金となることに注意してくださいね、というお話がありました。(これはPageBlobStorageならではですね)
そして、重要なのはデータを削除してもすぐには適用されないことで、週に1回、クリーニングバッチが流れると、データ削除時のサイズになるとのことです。
しかも、クイックフォーマットしないと消費サイズベースにならない、という落とし穴があるというお話がありました。うっかり忘れないようにしたいですね。

ただし、Premiumストレージは消費サイズベースではなく、定義ベースなので間違えないでくださいね!

  • キャッシュ

規定でOSのディスクは読み取り/書き込みキャッシュとなります。なのでSYSVOLなどはキャッシュなしのデータディスクにしましょう。

  • 性能

記憶スペースでディスクを束ねて、高いIOPSを構成しましょう。ただし、GRSの場合は整合性が崩れることがあるので注意が必要です!
そして束ねたディスクの災害対策はAzureBackupがベストプラクティスだそう。

「ネットワーク」

ロードバランサー、強制トンネリングなど、セキュリティグループなど。一般的なネットワーク構成をとることができますよ、というお話でした。

「バックアップ」

ファイル・データのバックアップであればAzure Backupを使えばOKとのこと。データ転送量もかからないのでお財布に優しいです。
仮想マシン単位のバックアップの場合はプレビューですがAzure Backup for IaaS VMがありますよ、とのことです。
他の方法としてストレージのスナップショットをとるやり方がありますが、この場合は不整合を防ぐために一度シャットダウンが必要となることをお忘れなく。

そして、バックアップデータの遠隔地保管については、Azure Backup(GRS)を使いましょう。

「セキュリティ」

やることは基本的にオンプレと同じだそうです。パスワードを複雑に、アプリケーションの脆弱性チェック、ファイアウォール、などなど。Azureそのもののセキュリティについてはものすごーく高いセキュリティを担保しているので、問題はそこではない、とのことです。じゃあどれぐらい高いのかを知りたければ、ホワイトペーパーを読んでね、とのことです。他機関からの認証も受けているから安心ですよ、とのこと。

意外と注意すべきなのは、管理ポータルへのアクセスだそうです。

  • パスワードが簡単だったり
  • 退職者IDが放置されていたり

これが穴となりやすいそうです。そしてこれを回避するには、Azure AD(組織アカウント)によるセキュリティ強化がおすすめ。オンプレのAD/ADFSと連携ができるので、退職したら自動的に管理ポータルへもアクセスできなくなるよ、とのことです。

さらに、多要素認証をかけることがおすすめだそうです。確かに、多要素認証かけておけば、万が一パスワード漏えいしても大丈夫ですからね。そして多要素認証だけなら、MSアカウントでも組織アカウントでも無償!!

そして、MSアカウントは、一定期間ログインしないと失効してしまうことに注意!だそうです。お客様のためにMSアカウント作って、そのままにしていたら失効してしまって、いざという時に使えなかった、ということが実際にあったそうです。そして、恐ろしいのは

Azureアカウント管理者のMSアカウントが失効すると、Azureサブスクリプションが削除されてしまうということです!!

いや、これは知りませんでした。危ないですね。

前半はここまでです。後半は次世代Azure IaaSの話です。


「Azure IaaS V2」

まず最初に、次世代のAzure IaaS V2はプレビューであり、しかも日本リージョンではまだサービス開始していない、という残念なお知らせがありました。そろそろ日本リージョンでのリリースを第1弾リリースの仲間に入れてほしいものですね。

Azure IaaS V2の目玉は色々あるそうですが、すいません、以下の3つしかメモれませんでした。(写真取ればよかった・・・)

  • 複数のVMをパラレルに展開可能に
  • 可用性セット内に3つの障害ドメイン
  • Azure Key Valutとの統合

いずれセッション資料と動画が公開されると思いますので、詳しくはそちらを。

セッションでの説明によると、最大の違いは基盤となる管理APIのモデルが変わります!とのことです。
今までのAzure Service Management(ASM)はXMLベースだったわけですが、これがAzure Resourcxe Manager(ARM)というJSONベースに変わる、と。

これによって、複数リソースから構成される複雑なシステムを、JSON形式のテンプレートで表現・展開できるようになるわけです。

このARMで変わることは以下のような感じだそうです。(もちろん、IaaSについての部分だけです)

  • 必ずクラウドサービスを作ることはなくなる。
  • 可用性セット、NICはVMとは分離した独立して管理可能となる
  • ロードバランサーもそう。
  • DNSも、パブリックIPリソースというリソースに指定可能なオプションになる

VMはPaaSに引きずられている形が多かったが、それがなくなる!ということで、これは嬉しいですね。

そして「リソースグループ」が大事な概念になるようです。プレビューポータル(現在はもうこちらが正式ポータルになりつつありますが)で見かけるリソースグループ。GUIでちまちまとIaaSやら仮想ネットワークやら作っているうちはあまり意味を感じなかったこのリソースグループですが、このARMの本格化に伴いとても重要な要素になりそうです。

話は戻りまして、ARMのJSONのテンプレートですが、手でいちから作る必要はありません。MSのサイトにテンプレートが公開されています

Azureクイックスタートテンプレート

f:id:nextscape_blog:20210909192322p:plain

Azureクイックスタートテンプレート、で検索して適当なテンプレートを選びます。現在公開されているだけで、72ものテンプレートがあるようです。

f:id:nextscape_blog:20210909192351p:plain

この中から1つを選んでリンクをクリックしたら、中にあるDeploy to Azure ボタンをクリックするだけで JSON ファイルがAzure上に展開されます。そのままデプロイするも良し、少し加工するも良し。なんて便利なんでしょうか。

そしてこのテンプレート、どういう訳だかgithubにもあるようです。

https://github.com/Azure/azure-quickstart-templates

それともう一つ、Visual Studioを使う方法が紹介されました。専用のプロジェクトテンプレートがあるのでそちらで新規プロジェクトを作れば、JSONの加工をGUIでできるようになります。

f:id:nextscape_blog:20210909192432p:plain

また、プレビューポータルの各リソースへのタグ付け(タグはKeyとValue)をすることによる管理も便利なのでぜひ!とのことでした。

あとは可能な操作を絞り込んだ権限を渡したい場合にはRBAC(Role-Based Access Control)のご利用を検討しましょう、という話がありました。
担当者への管理権限へ委譲が必要ですが、セキュリティや誤操作が心配。という場合にぜひ。

最後に、Azure Resource Explorer というツールの紹介がありました。Webアプリなのですが、これを使うとその時にログインしているMSアカウントに紐づくAzureのサブスクリプションが全て表示されて、各リソース情報をJSON形式で見ることができます。ARMの理解が深まるし、おもしろいですよ!

このARM、Infrastructure as Codeの時代である、ということがよくわかりますね。

レポートは以上になります。
次世代IaaSの話が面白くて、前半のTips系の話はどこかに行ってしまいそうな感じですね!個人的には前半の内容のように、Azureを使うなら積極的にPaaSを使っていく方向がお勧めですが、そうはいってもやはりいざというときにはIaaS、ということが多いのも現実です。どちらも深く理解しておく必要がありますよね。

実りあるセッションでした!