COLUMN

1.AWSのネットワーク設計時に注意したいポイント

業務システムをクラウドへと移行することが増えた現代で、ネットワーク設計を見直さなかったために、移行後、通信速度が悪化してしまったという問題を抱える企業は少なくありません。AWSのネットワーク設計時に注意したいポイントとしては、以下の3つがあります。

• オンプレミスとの違いを明確にする
• VPCを活用する
• セキュリティグループを設定する

順番に見ていきましょう。

1-1.オンプレミスとの違いを明確にする

AWSとオンプレミスの最大の違いは「物理設計が不要」という点です。AWSではサーバーや配線ケーブル、ネットワーク機器の調達や設置をする必要がなく、ネットワークをすぐに構築できます。特にネットワーク設計では物理的な配線のようなものがなくなるのは非常に大きなメリットです。論理設計したあとに、物理に落とし込むという手間もなくなり、オンプレミスのネットワーク設計のように苦労することがありません。

1-2.VPCを活用する

AWSを使うにあたって「VPC」（Virtual Private Cloud）の知識は欠かすことができません。「VPC」はインスタンスを入れておく「箱」のようなイメージをしていただければよいでしょう。AWSでは、まず“東京”“オレゴン”などの「リージョン」を選んで、その中にVPCを作成します。VPCの中は自分たちだけのプライベートIPアドレスで利用する空間、VPCの外側はパブリックIPアドレス空間となります。

1-3.セキュリティグループを設定する

セキュリティグループを使用すると、どのトラフィックがインスタンスに到達できるか、あるいはインスタンスからどのトラフィックを発することができるかなど、トラフィックを細かく制御できます。たとえば、会社や自宅からのコンピューターのみがSSHを使用して、インスタンスにアクセス可能なように許可することができます。インスタンスがWebサーバーの場合、すべてのIPアドレスがHTTPまたはHTTPSを使用してインスタンスにアクセスできるようにすることで、外部ユーザーはWebサーバーのコンテンツを閲覧できます。

AWSのネットワーク設計について、お気軽にNTT東日本までご相談ください。

2.ネットワーク障害に備えて行っておく対策

ネットワーク障害に備え、はじめに行っておくべき対策には、以下のものがあります。

• リスク分散
• 監視・復旧体制の構築

本記事ではAWSのネットワーク設計や運用について解説していますが、ネットワーク障害はAWSだけでなく、どのようなクラウドでも起こる可能性があるものです。クラウドを使用して業務を行う際は、障害は起こるものといった前提で、影響を最小限に留める対策を行いましょう。

2-1.リスク分散

ネットワーク障害に備えて行っておくべき対策は、リスク分散です。AWSには「Availability Zone」（AZ）というデータセンター郡の概念があります。

Availability ZoneとはAWSの各リージョンの中で、自立して存在するデータセンター群のことです。たとえば東京リージョンには4つのAvailability Zoneがありますが、それぞれのAvailability Zoneは「互いにすべて100km（60マイル）以内」かつ、「それぞれのAZから物理的に意味のある距離（数キロメートル）離れた場所」に設置されています。サービスを複数のAvailability Zoneに分散して利用することで、リソースを分散し、冗長化を実現して、高い耐障害性を実現できるのです。

Amazon RDSの場合、Multi-AZ配線を使用して、容易に複数のAvailability Zoneにリソースを分散させることができます。またAmazon S3やAmazon EBSであれば、常に別リージョンにバックアップを持っていくといったリスク分散が必要といえるでしょう。

2-2.監視・復旧体制の構築

ネットワークの監視は、障害発生時に発生箇所を切り分けるためにも重要です。AWSが提供する「フルマネージド運用監視サービス」には「CloudWatch」があり、AWSの各種リソースを監視してくれます。セットアップ不要で使用することができ、EC2やEBSなど、いろいろなサービスの稼働を監視できます。メトリクスに応じてアラート通知や、アクションを設定することにより、異常な状態を検知するところから自動での復旧まで可能です。

3.AWSネットワーク運用における注意点

AWSネットワークの運用は、以下の点に注意することが必要です。

3-1.サービスの選択

AWSには非常に多くのサービスが登録されていますので、自社にとって最適なサービスを選択し、組み合わせて運用するようにしましょう。運用しようとするサービスやシステム、データの重要度、可用性要件、予算等によって、必要なスケールや要求されるパフォーマンス、運用の体制、適切なサービスなども異なります。

3-2.運用負荷とコストの節減

AWSは、サービスおよび料金オプションの幅広さにより、必要なパフォーマンスとキャパシティーを維持しながら、効果的にコストを管理できる柔軟性を実現しています。そのため、予約（リザーブド）インスタンスや待機（スポット）インスタンス等を効果的に使用すればコストの最適化を図ることができるでしょう。またコスト管理ツールを使用してモニタリングすれば、コストをほぼリアルタイムに把握できます。

3-3.セキュリティ

AWSにおいては、以下のようなセキュリティ管理をして、ネットワーク運用を行うとよいでしょう。

3-3-1.セキュリティグループの管理

IAMユーザーの管理、権限の分散と管理に関して、組織の議論を踏まえて体系的に設定運用を行いましょう。

3-3-2.パスワードの管理

AWSアカウントから、IAMユーザーのパスワードの複雑な要件や必須の更新期間を指定するパスワードポリシーの設定が可能です。AWSでの運用にとどまりませんが、パスワードは厳重に管理し、流出が起きないように配慮しましょう。

3-3-3.バックアップ体制の用意

定期的にAMIやスナップショットを取得し、障害時に速やかな復旧ができるようにしておきましょう。データライフサイクルマネジャーといったツールを利用すると、簡単に定期バックアップを取ることが可能です。

3-4.外部リソースの活用

ネットワークの運用や監視、24時間365日の対応体制などについては外部のコンサルティングや運用サポート専門の会社への委託など、外部リソースを適切に利用するとよいでしょう。

4.AWSのネットワーク速度が遅い場合の対策

ネットワークが遅い場合、その原因がどこにあるのか切り分けて考えることが必要です。たとえばオフィスとAWSとをつなぐ回線に問題があったり、メモリ不足だったり、考えられる点は多くあります。またAWSのネットワーク自体を高機能化する方法もあるため、当初想定していたような速度が出ない場合には、次の点を検討してみましょう。

4-1.ネットワークの輻輳化やネットワーク機器の確認

基本的なことですが、AWSとオフィスを接続しているネットワークの回線上に多量のトラフィック（通信）が生じていないか確認しましょう。AWSの反応が遅いのではなく、クラウドとオフィスの端末を結ぶネットワーク回線自体の輻輳に原因がある場合もあります。輻輳が発生した場合、オフィスとクラウドとの通信速度が次第に遅くなっていき、さらにひどくなると回線がつながりにくくなったり、通信システムそのものがダウンしたりといった現象が起こります。またルーターやスイッチなどのネットワーク機器のパフォーマンスについても確認しましょう。

NTT東日本でまとめた資料「比べて納得！クラウドへの接続方法」は、こちらよりダウンロードできますので、併せてご確認ください。

4-2.アベイラビリティーゾーンの適切配置（Multi-AZ配置の注意）

複数のアベイラビリティーゾーンにシステムを配置（Multi-AZ配置）してシステムの耐障害性を高めることは重要ですが、アベイラビリティーゾーンをまたいだ通信を行う場合には、コスト増と速度低下を招くことがあるため注意しましょう。配置の計画に際して留意しておかなければ、処理パフォーマンスが著しく低下する場合があります。Multi-AZ配置にするとAZ間の通信が発生してしまうので、どうしてもパフォーマンスが落ちる傾向がありますが、特にアプリケーションサーバーがAZをまたいでRDSに書き込む構成になっている場合、はっきりと差がわかるくらいパフォーマンスが落ちます。これを避けるには、アプリケーションサーバーとRDSのマスターを同じAZに置くようにしてみてください。

4-3.ネットワークの高性能化（Linuxの拡張ネットワーキングの使用）

Linuxの拡張ネットワーキングを用いることで、ネットワークの高速化が可能です。拡張ネットワーキングでは、シングルルート I/O 仮想化 (SR-IOV) を使用して、高性能ネットワーキング機能が提供されます。SR-IOVは、従来の仮想化ネットワークインターフェイスと比較し、I/Oパフォーマンスが高く、CPU利用率が低いデバイス仮想化手法です。拡張ネットワーキングは、高い帯域幅、1秒あたりのパケット（PPS）の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。インスタンスタイプに応じて、Elastic Network Adapter（ENA）、あるいはIntel 82599 Virtual Function（VF）インターフェイスのいずれかを使用して、拡張ネットワーキングを有効にできます。

4-4.メモリ利用率の監視（CloudWatchなどの利用）

ネットワークが低速である原因の一つに、システムのメモリマネージメントが適正化されていないという場合があります。「フルマネージド運用監視サービス」である「CloudWatch」のカスタムメトリクスで、メモリ使用率の取得が可能です。システムが過剰にメモリを消費していないか、チェックを行いましょう。

4-5.スループットの改善（EBSボリュームタイプの選択）

Amazon EBSでは2つのボリュームタイプを提供しており、アプリケーションのニーズに応じてストレージのパフォーマンスとコストを調整できます。これによってスループットを改善できる場合があります。

• I/Oサイズの小さい頻繁な読み取り／書き込み操作を含むトランザクションワークロード用に最適化されたSSD-Backedボリューム。主要なパフォーマンスの測定効果はIOPS（※）です。
• 大きなストリーミングワークロード用に最適化されたHDD-Backedボリューム。パフォーマンスの測定単位としては、IOPSよりスループット（MiB/秒単位で計測）の方が適しています。

IOPSとは、1秒当たりにディスクが処理できるI/Oアクセスの数のことです。1回のI/O処理にかかる時間は、データ転送時間と平均アクセス時間とを足した数値になります。I/O処理を1秒当たり何回実行できるかの数値がIOPSです。

4-6.Amazon ElastiCacheの利用（キャッシュの有効化）

キャッシュの有効化によりネットワーク速度を改善する方法もあります。Amazon ElastiCacheは、Memcachedまたは Redisプロトコルに準拠するサーバーノードのデプロイと実行を、クラウド内で簡単に実行できるWebサービスです。低速のディスクベースのデータベースに全面的に依存することなく、管理された高速のインメモリシステムから情報取得を可能にして、Webアプリケーションのパフォーマンスを向上させます。

4-7.インスタンスのパフォーマンス改善（EC2インスタンスタイプの見直し）

Amazon EC2は、さまざまなユースケースのために最適化されたインスタンスタイプの幅広い選択肢を提供しています。インスタンスタイプはさまざまなCPU、メモリ、ストレージ、ネットワークキャパシティーの組み合わせによって構成されているため、アプリケーションのリソースとして適切な組み合わせを柔軟に選択できます。ネットワーク速度が遅い場合、このインスタンスタイプを見直してパフォーマンスの改善を図る方法があります。

4-8.Webサイトを高速化する（CloudFrontの利用）

Amazon CloudFrontは世界100箇所のエッジロケーション（キャッシュサーバー）を配置して、最短距離でコンテンツを配信するCDN（コンテンツデリバリーネットワーク）です。Webサーバーをオリジンサーバー（元データを格納するサーバー）としてAmazon CloudFrontに登録し、Webページ内のコンテンツリンク先をキャッシュ参照用URLに変更することで、Amazon CloudFrontがオリジンサーバーからデータを取得できます。これにより、Webサイト訪問者に短距離でコンテンツが配信されるだけでなく、同一コンテンツに繰り返しアクセスのあるWebサイトの高速化が可能です。

4-9.MQTTのQoSを適切に設定する

AWSのネットワーク速度が遅い場合の対処法として、MQTTのQoSを適切に設定する方法もあります。最後に、MQTTの概要や仕組み、QoSレベルについて見ていきましょう。

4-9-1.MQTTの概要・仕組み

MQTTとは「Message Queuing Telemetry Transport」の略で、リソースに制約のあるデバイスや、低帯域または高遅延などにより信頼性の低いネットワーク向けに設計された、パブリッシュ・サブスクライブに基づくメッセージングプロトコルです。MQTTはシンプルかつ軽量に設計されているため、IoTアプリケーションの使用に適しており、インターネットに接続されたデバイスから、クラウドアプリケーションへ安全に通信するためのプラットフォームである「AWS IoT Core」でも使用されています。

MQTTの仕組みを解説する前に、解説に必要となる3つの単語「Publisher」「Subscriber」「Broker」について見ていきましょう。

• Publisher（パブリッシャー）：メッセージを送信する側や、メッセージを送信する処理を行うプログラム
• Subscriber（サブスクライバー）：メッセージを受信するプログラム
• Broker（ブローカー）：パブリッシャーからメッセージを受け取り、サブスクライバーに送信するサーバー

MQTTは、PublisherがBrokerにメッセージを送信し、SubscriberがBrokerにメッセージを受信しに行く仕組みとなっています。MQTTではPublisherがBrokerに送信したメッセージをSubscriberが受け取りに行った際、Brokerは複数のSubscriberにメッセージを配信できますが、非同期通信であるため、Publisher側に負荷はかかりません。

4-9-2.MQTTのQoSレベルとは

IoTアプリケーションの使用に適しているMQTTには、メッセージ配信の信頼性をさまざまなネットワーク環境下で保証する三段階の「QoS（Quality of Service）レベル」があります。

• QoS 0：Publisher、Brokerともに、送信したメッセージが相手にしっかりと届いたかという確認を行わず、再送する仕組みもないレベル
• QoS 1：単純な再送メカニズムが含まれたレベル。メッセージ送信後に受信者からのACK（データの送受信を確認する信号）がなければ、メッセージの再送を行うレベル
• QoS 2：メッセージが一度だけ到着することを保証するために、再送する仕組みと重複を検知する仕組みが用意されたレベル

AWS IoT Coreでは、レベル0と1がサポートされています。それぞれのQoSレベルを選択する際のユースケースについてかんたんに記載しますので、ぜひ参考にしてください。

＜QoS 0を選ぶユースケース＞

• たまにメッセージが失われることを受け入れられる
• 同じサブネット内の内部サービスとしてMQTTを利用する
• クライアントとサーバーのネットワーク間が非常に安定している

＜QoS 1を選ぶユースケース＞

• QoS 2では重たいが、パフォーマンスの最適化をしたいと考えている
• メッセージを失いたくないが、メッセージの重複については処理が可能である

QoSが上がるほどリソースの消費は多くなります。自社の環境や上記のユースケースを参考に、最適なレベルを選ぶことが大切です。

5.AWSのネットワーク設計・運用ならNTT東日本へご相談ください

本記事ではAWSのネットワーク設計や、運用後における注意点を解説しましたが、いざ自社でネットワーク設計を行おうとしても、本当に合っているのか、対策は行えているのかと不安になる企業も少なくないでしょう。AWSのネットワーク設計や運用に迷ったら、NTT東日本へご相談ください。

NTT東日本であれば、豊富な実績を持つクラウドのプロが、クラウド化について「分からない」と思ったり、「面倒」と感じたりする問題を解決します。ストレスと手間を減らし、クラウドを導入前から導入後のすべての作業についてワンストップサポートを行うため、ご担当者さまは本当にやるべきことのみに集中できます。

NTT東日本のクラウド導入・運用サービスは以下のページで詳しく解説していますので、ぜひ見てみてください。

NTT東日本のクラウド導入・運用サービス

6.まとめ

急激に進んだDXの推進により、多くの企業がクラウド化に踏み切る中で、自社でも業務システムを早急にクラウド化しようと、ネットワーク設計を怠ってクラウド化に踏み切る企業も少なくないでしょう。しかしクラウド化には導入前に行うべき対策や、導入して利用を始めてから、考えなければいけない改善点が数多くあります。

自社に合ったクラウド化を行わなければ、通信速度が悪化し、業務に支障が出てしまう場合も考えられるため、ネットワーク設計時に注意したいポイントから、ネットワーク障害に備えて行っておく対策など、本記事で紹介した方法を、ぜひ試してから行ってみてください。

また対策を行った場合でも、いざ運用し始めてから、ネットワーク速度が遅いと感じることもあるため、速度が遅い場合の対策を頭に入れておく必要もあります。クラウド移行の経験が乏しい場合、導入前や運用後に対策を行うことは、大きな負担になってしまうでしょう。

NTT東日本であれば、AWSの導入から運用までをサポートできる「クラウド導入・運用サービス」があります。クラウド導入設計からネットワーク構築、セキュリティ、運用までワンストップサポートを行えるため、たとえIT専任の担当者がいない企業でも、安心してクラウドサービスが使えるようになるでしょう。

よりリーズナブルに、早くかんたんに、おすすめのクラウド環境を提案できるNTT東日本のクラウド導入・運用サービスを、ぜひお試しください。