こんにちは。株式会社パイプラインの濱田です。

クラウドに限らず、オンプレミスでも悩ましいのがインフラのサイジングです。
マシンスペックは勿論のことですが、ネットワーク設計もスケーリングを考慮する必要があります。
今回は開発から運用までのフェーズにおけるサイジングの考慮点について取り上げます。

開発時のマシンスペックはミニマムで

言うまでもなく、クラウドの利用料金はインスタンスの利用時間とマシンスペック、トラフィックの転送量に左右されます。

これから開発するサービスの期待値が高く、いわゆる「最初からバズることがわかっている」という状態であっても、開発時はなるべくマシンスペックを必要最小限にしておくことをおすすめします。

筆者も昔、あるサービスをオンプレミスからクラウドへ移行する際に、高性能な現行サーバーのスペックそのままに開発の初期からインスタンスを建ててしまい、慌ててインスタンスのスペックを一時的に下げたことがあります。

性能要件としてわかってはいても、開発期間中から大量のアクセスがあるわけではない、という当たり前のことを見落としていたのです。それからは、開発期間中のマシンスペックについてお客様や関係者と密に意識合わせする習慣を心がけています。

ネットワークのサイジングは余裕を持とう

さて、IaaSにおける仮想サーバー インスタンスのサイジングについては要件によって、あるいは性能試験の実測値に基づいてスケーリングすることが容易であることはイメージしやすいかと思います。
しかし、ネットワークのサイジングについてはどうなのでしょうか。

クラウド利用者がもっとも意識しなければならないネットワークのスケーリングとは、サブネット設計だと言っても過言ではないでしょう。
1つのサブネットに何台のインスタンスを建てるのか、また、何台までスケーリング可能かといった要件を踏まえてサブネット設計をすることを強くおすすめします。

運用設計はプロジェクトの後半に開始されることが多いのですが、こうしたサイジングが運用の制約事項になってしまわないよう、運用要件から逆算してサイジングを行うことが肝要です。

特に、金融機関や特定の企業間での閉域網などをクラウド上に構築する要件がある場合、相手先ネットワークとの相互接続性やセキュリティレベルを考慮する必要があります。

自社でグローバルIPv4アドレスを持っており、これをBYOIPという形でクラウド環境へ持ち込むようなケースを除き、ほとんどのケースにおいて、VPCやVNetと呼ばれるネットワーク環境を構築するでしょう。

ですので、各クラウド事業者の仕様や制約事項は慎重に確認する、場合によってはサポートを仰ぐことも検討することをおすすめします。

ネットワーク要件定義においての考慮ポイントをまとめると

• VPCやVNet"内"でどれだけアドレス拡張しそうか、という観点
• 対外接続が何拠点ありそうか、そして今後どれだけ増えそうか、という観点
• 対外接続先のアドレス体系や利用プロトコル、発信契機などの通信パターン洗い出し

など多岐にわたります。

また、業務要件観点のみならず、各クラウド事業者の仕様や制約事項、RFCなどの規格をはみ出るような設計になってしまうと追加開発や仕様変更などのリスクが伴います。ご参考までに、クラウド事業者各社のネットワーク仕様の参考になるリンクを張りますので確認してみましょう。(勿論これが全てではありませんが)

---

[AWS]

• How Amazon VPC works
• Amazon VPC の IPv4 CIDR ブロックを変更する方法を教えてください。

[Microsoft Azure]

• Azure Virtual Network についてよく寄せられる質問 (FAQ)

[Google Cloud]

• Virtual Private Cloud（VPC）の概要

---

まずはエンジニアデビューしたい、という方は、3 ヶ月間学びながらお給料が貰える 株式会社AltX キャリテク!の門を叩いてみてはいかがでしょう。
https://www.kcct.co.jp/careetec/