Azure を自社に導入する前に検討しておきたい事を「５つの項目」にまとめてみました。この「５つの項目」への答えを準備できていると、スムーズな導入が期待できます。
【社内ルール編】
[Microsoft Azureの購入方法を検討する]
先ずは、Azureの購入方法から検討していきましょう。詳細は「Azureの購入方法」に記載しています。プランに迷う方は、下記チャートをご活用下さい。 ※ちょっと強引ですが、、
[社内向け利用申請書を作成する]
社内でAzureを利用する場合、おそらく、様々な部署や事業所の方も利用したいと思います。その為の申請フローや申請書のテンプレートを作成しておくと良いでしょう。この申請書と設定シートを兼用するのも有用かと思います。
[社内向け請求方法を考える]
社内でAzureを利用した場合、利用した部署や事業所に対して、社内請求をしたい場合があります。占有するサービスは請求しやすいのですが、共有するサービスは人数割りなど、事前に取り決めておいた方が良いでしょう。また、そう言った細かい計算を省くために、自社用の料金メニューを作成しておくのも良いかもしれません。
Azureの利用明細はサブスクリプション単位で発行されるので、1部署＝1サブスクリプションとするのが、最も手っ取り早いです。ですが、Azureから見たサブスクリプションはサービスの提供範囲やリソースの上限値を決めるので、注意が必要です。特に一番困りそうなのが、[Azure Active Directory]を利用する場合サブスクリプション単位で分割されてしまうので、ID同期などは少し手間がかります。
※サブスクリプションではなく、タグ機能を利用する事で、費用をまとめる事も可能です。
【Azureポータルサイト編】
[Azureポータルサイトの管理者と役割を決める]
誰がAzureを管理するのかを決めておきましょう。情報システム部門で一括管理を行うのか、各部署単位で行うのか、Azureサービスの作成者やトラブル対応者、課金閲覧者など、予め、役割と責任範囲を決めておきましょう。幸いAzureのポータルサイトには「RBAC機能」がありますので、活用しましょう。また、監査ログの取得も考えておきましょう。
[Azureポータルサイト内での命名規則]
Azure内で作成する、リソースグループや仮想マシンなどの命名規則を決めておきましょう。すでに利用している命名規則を、そのまま利用しても結構です。
迷う際は、[場所＋役割＋通し番号]とか如何でしょうか？
例：西日本に設置したファイルサーバーの場合、[JPW-FS01]
【ネットワーク編】
[Azureとの接続方法を考える]
オンプレミスサイト(拠点)とAzureを接続する際の考え方ですが、３層に分けることで理解が進むと思います。それぞれの層で要件に適したパターンを選択する事で、簡単にネットワークの設計ができます。
必ず「Azure VPN Gateway デザインパターン」を確認して下さい。
[IPセグメントを検討する]
基本的には拠点側で未使用のIPセグメントを選択して頂ければ問題ありません。VPNGatewayやExpressRouteでは、スタティックNATが設定できないので、拠点側と重複するIPセグメントは付与できません。また、Azure経由で接続する拠点同士でも重複があってはいけません。ですが、どうしても拠点同士での重複が避けられない場合もあるかと思います。
※個人的には無理をしてでも、一方のIPセグメントを変更して欲しいのですが。。
その場合は拠点側のルーターにてNAT設定を実施して頂ければ重複状態でも接続できます。
[Azureでのネットワーク構成を考える]
ネットワーク構成を考える上で重要なのは、「通信フロー」です。先ずは、必要な通信を全て洗い出してみて下さい。例えば、インターネットへの通信やDNS、RDP、認証などの通信を、どのような経路で通したいのかを”まとめ”て下さい。
インターネット向けの通信は全て、オンサイト拠点経由にしたいとか、外部ベンダーにインターネット経由でメンテナンスしてもらう必要があるとか、DMZセグメントを設けたいとか、色々あるかと思いますが、出揃った時には、ネットワーク構成が完成しています。マルチリージョンの場合も同様で、各リージョンで完結させるのか、HUBリージョンを設けるのか、フローを意識して下さい。
※サブネットは、サーバーの役割単位、NSGのフィルター単位で分割する方が良いでしょう。
【セキュリティ編】
[Azureでのセキュリティを考える]
既にセキュリティポリシーが存在するかと思います。そこで、確認する必要があるのは、Azure環境でそのポリシーを満たせるのかどうかと言う事です。
セキュリティポリシーが無いのであれば、Azureを考慮したポリシーを策定するのもいいかと思います。
情報セキュリティの三要素に当てはめてみると
[機密性]
Azure Active Directory / Azure Active Directory B2C / Multi-Factor Authentication / Azure Active Directory Domain Services
[完全性]
Key Vault / UDR / NSG / Azure Disk Encryption / Azure Storage Service Encryption / Always Encrypted / Transparent Data Encryption
[可用性]
RA-GRS / Site Recovery / Availability Set / Availability Zone / Load Balancer / Application Gateway / Backup / Traffic Manager / Content Delivery Network /
Media Services / StorSimple
※セキュリティ向け仮想アプライアンス(NVA)がサードパーティより提供されています。
【HA/DR編】
[Azureでのハイアベイラビリティを考える]
ここでは「HA」＝同一リージョン内での、サービス停止を伴な言わない切り替えと定義します。
仮想マシンで「SLA 100％」に近づけるには、複数台の仮想マシンで構成し、必ず可用性セットを適用して下さい。ロードバランサーも無償で利用できますので、合わせて活用下さい。ただし、Azureのサービスとして、データを同期する方法が提供されておりませんので、考案する必要があります。
※Windows2016の機能”記憶域スペースダイレクト“を使うとサーバー間でデータの同期ができます。
みなさん、当然ながら”SLA 100%”環境を希望するかと思いますが、その分コストがかさみます。先ずは、許容できる停止時間を調べてみましょう。冗長構成をとる必要が無いかもしれません。
※PaaSは、リージョン内での冗長構成を考慮されたサービスです。
[SLA 停止時間表]
[Azureでのディザスタリカバリを考える]
ここでは、「DR」＝ペアリージョン間での、サービス停止を伴う切り替えと定義します。
Azureでは必ずペアとなるリージョンが存在します。日本の場合、東日本リージョンと西日本リージョンになります。
プライマリリージョンが災害に見舞われた際には、セカンダリリージョンでの復旧方法を準備しておくと良いでしょう。
IaaSの場合、Azure Site Recovery (ASR)を利用すれば、簡単にリージョン間の冗長構成が組めます。
ただし、PaaS サービスにディザスタリカバリ機能は提供されておりませんので、自身で考慮する必要があります。
※SQL Database の Geo-Replication、AlwaysOn ぐらいでしょうか。
ちなみに、DRに対応できそうな、Azureサービス
・BLOB(RA-GRS)：任意のタイミングで実施可能。ただし、静止点が取れない。
・Azure Backup：Microsoftがリージョン停止を認定した時のみ利用。※過去一度も認定無し
・Azure Site Recovery (ASR)：Azureリージョン間で冗長構成が組める。
[監視方法を考える]
既に監視システムがある場合、Azure上の仮想マシンも対象に含めても良いでしょう。
Azureポータルサイト上には、”パフォーマンスモニター”が提供されています。
仮想マシンの場合、[CPU使用率][Disk in/out I/O][Disk in/out データ量][Network in/out データ量]を監視しアラートメールの送信が可能です。
また、Log Analyticsを利用する事で各種ログの[監視/診断/収集/保管/分析/可視化/アラート]収集と可視化が可能です。
※Azureの機能の中で死活監視やSNMP監視を提供するものはありません。
※System Center Operations Managerなら、オンプレ機器もAzure(IaaS、PaaS)も監視可能です。
また、”Azureサービス正常性”では、全リージョンのメンテナンス予定、障害情報などが提供されています。”Azureモニター”と組み合わせる事でメール通知させる事も可能です。
Azureを導入する際に気になりそうなポイントを書き連ねてみました。スムーズな導入の手助けとなれば幸いです。
