第68回ブログ｜ビットオンのインフラ選択の考え方 ― さくらVPS・さくらのクラウド・AWS・Azure・GCPをどう選ぶか

ビットオンのインフラ選択の考え方のイメージ

ビットオンでは、数多くのお客様のシステムをAWS,GCP,Azure,さくらにて運用しております。AWS採用案件が多いのは事実ですが、 企業向けシステムのインフラを選ぶとき、「どのクラウドが一番良いか」という比較から入ると、かえって判断が難しくなることがあります。 実際の案件で重要なのは、ベンダーの知名度や流行だけではなく、その案件に対してどの基盤が過不足なく合っているかを整理することです。

ビットオンでは、インフラ選定を単純なブランド比較で決めるのではなく、案件の規模、構成、運用責任、将来拡張の可能性、顧客側のIT環境との整合性を順番に確認しながら選ぶようにしています。 特に日本の企業案件では、最初から大規模クラウドを前提にしなくても、十分に成立する案件が少なくありません。

当社では、Dockerベースでアプリケーション、DB、ファイル保存、バッチなどを構成し、Composeレベルで再現しやすい形に整えたうえで、必要十分な基盤から始めることを重視しています。 そのうえで、実際に拡張が必要になった段階で、より柔軟なクラウド基盤に寄せていくという考え方を採っています。

この記事で整理すること

1. まず前提として考えていること

ビットオンでは、インフラ選定をするときに、最初から「標準だからAWS」「クラウド時代だからマネージドを前提にする」とは考えていません。 まず見るのは、その案件が本当に大規模クラウドを必要としているかどうかです。

日本向けの企業案件では、利用者数や負荷がある程度読みやすく、Webアプリ、DB、ファイル保存、バッチ処理まで含めても、単一サーバーまたは少数サーバーで安定運用できるケースが多くあります。 しかも、DockerとComposeで構成管理できていれば、あとから移設しやすい形を保ちやすくなります。

そのため、当社では「最初から拡張性にコストを払う」よりも、「移行可能性を確保したうえで、まずは必要十分な基盤で始める」ことを重視しています。 この考え方は、コスト面だけでなく、構成の単純さ、障害時の見通しの良さ、顧客への説明のしやすさにもつながります。

2. ビットオンのインフラ選定の基本順序

インフラ選定では、概ね次の順序で確認しています。

  1. Composeレベルで閉じられる構成かどうか
  2. 単一または少数サーバーで運用可能かどうか
  3. 国内向け案件として完結するかどうか
  4. スケールアウトや負荷分散が早期に必要かどうか
  5. 顧客が監査・統制・クラウド標準を求めるかどうか
  6. Microsoft系資産との統合が重要かどうか
  7. 分析・AI・Google系サービス連携が重要かどうか

この順番で見ると、必要以上に大きな基盤を最初から選びにくくなります。 また、案件に対して何を優先した選定なのかを、顧客にも説明しやすくなります。

3. まず検討するのは「さくらVPS」で足りるかどうか

最初に検討するのは、その案件がさくらVPSで十分成立するかどうかです。 ここでいう「十分」とは、単に動くという意味ではなく、性能・運用・保守・障害対応を含めて、現実的に回せるかどうかを指します。

次のような条件であれば、ビットオンではまずさくらVPSを有力候補として考えます。

このタイプの案件では、VPSは非常に合理的です。 特に当社のように、Dockerベースで構成管理し、Linuxやミドルウェア運用を自社で握れる場合は、最初から高機能クラウドに寄せなくても実務上困らないケースが多くあります。

さくらVPSが向いている典型例としては、会員サイト、企業向け業務システム、予約管理、申請ワークフロー、BtoBポータル、APIサーバー、小規模から中規模のSaaSなどが挙げられます。 こうした案件では、システム全体よりも、まず安定して動き、保守しやすく、コストが読みやすいことのほうが重要な場合が少なくありません。

4. VPSでは足りないが、国内向けで完結するなら「さくらのクラウド」

次に検討するのは、VPSでは少し窮屈だが、まだAWSやAzureのような総合クラウドの厚い周辺機能までは必要ないケースです。 このとき、ビットオンでは「さくらのクラウド」を有力候補として考えます。

たとえば次のような条件です。

さくらのクラウドは、VPSよりもクラウド的な柔軟性を持たせやすい一方で、日本国内向け案件には十分な現実性があります。 ビットオンでは、国内で完結するシステムで、少しクラウドらしい構成が必要になった段階で、まずここを検討するという順番を取りやすいと考えています。

これは「VPSの上位版」という意味ではなく、Compose中心の構成から、少しずつ負荷分散や冗長性を持たせた構成へ移るための自然な中間地点として捉えています。

5. 企業統制や標準クラウド運用が必要なら「AWS」

AWSを選ぶ理由は、単に仮想サーバーを借りるためではありません。 ビットオンでは、AWSは「企業向けのクラウド標準部品を活用する必要がある案件」で優先度が高くなると考えています。

AWSを有力候補にするのは、たとえば次のような場合です。

こうした要件がある場合、AWSは単なるIaaSではなく、企業運用そのものを整理しやすい基盤になります。 ビットオンでは、案件の責任分界を考えた結果としてAWSが自然である場合に選ぶ、という位置づけで見ています。

逆に、国内向けの単純な企業案件で、そこまでの統制機能や周辺マネージドサービスが不要であれば、最初からAWSを選ばなくても十分な場合があります。

6. Microsoft中心の企業ITと合わせるなら「Azure」

Azureは、一般的なクラウド基盤として選ぶこともできますが、ビットオンでは特にMicrosoft製品や企業内ITとの親和性が高い案件で検討優先度が上がると考えています。

Azureを有力候補にする条件としては、次のようなものがあります。

このような場合、Azureは単なるクラウドというより、既存の企業IT資産に自然に接続できる基盤として意味を持ちます。 顧客の情報システム部門や既存運用とのつながりを重視する案件では、Azureが最も説明しやすい選択になることがあります。

7. 分析・AI・Google系サービスが主役なら「GCP」

GCPも汎用クラウドとして利用できますが、ビットオンでは特にデータ分析、AI活用、Google系サービスとの接続が案件の中心にある場合に優先度が上がると考えています。

たとえば次のような条件です。

このタイプの案件では、GCPは単なるサーバー置き場ではなく、分析やAIの基盤そのものとして意味を持ちます。 一方で、そこが案件の主軸でなければ、国内企業案件において必ずしも第一候補になるとは限りません。

8. 「Composeで足りるなら、まず小さく始める」という考え方

なお、コンテナ運用の延長として、Kubernetes（一般的にはK8sと略されます）をいつ検討するかも、実務では重要です。 Kubernetesはコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための基盤であり、複数ノードにまたがる運用、冗長化、自動復旧、段階的な更新が必要になる案件では強い選択肢になります。

ただし、ビットオンでは「Dockerを使っているなら、すぐにKubernetesへ進む」とは考えていません。 単一サーバーまたは少数サーバーで十分に回り、Composeレベルで再現性と保守性を確保できるなら、まずはそこに留めたほうが構成がわかりやすく、運用コストも抑えやすいからです。

一方で、次のような条件が見えてきた場合は、Kubernetesを視野に入れる価値が出てきます。

つまり、ビットオンの考え方としては、「ComposeかKubernetesか」を流行で決めるのではなく、案件の規模、運用体制、障害時の責任分界、将来の拡張要求で決める、ということです。 小さく始める段階ではComposeが合理的であり、複雑さを受け入れてでも運用自動化や分散配置の価値が上回る段階で、Kubernetesが自然な選択になります。

ビットオンでは、多くの企業案件が、初期段階ではComposeレベルで十分成立すると考えています。 アプリケーション、DB、ファイル保存、バッチ処理、リバースプロキシまでをDockerベースで管理できるなら、まずは小さく始める判断をしやすくなります。

ここで重要なのは、「将来の拡張性を無視する」ことではありません。 そうではなく、最初から過剰な基盤を選ぶのではなく、あとで移れる形を確保しながら、まず現実的な基盤で始めるという考え方です。

特にDockerベースで運用していれば、少なくともアプリケーション実行環境の再現性は確保しやすくなります。 もちろん、実際の移行ではDB、ファイル、バックアップ、ネットワーク、監視、DNS切り替えなどの設計は別途必要です。 それでも、アプリケーションの移植可能性を高めておくことには大きな意味があります。

9. ビットオンの判断基準を簡潔にまとめると

案件条件ごとに整理すると、ビットオンでは概ね次のように考えています。

案件条件 優先的に検討する基盤 考え方
Composeレベルで閉じられ、単一または少数サーバーで成立する さくらVPS まずは必要十分な基盤で始める
国内向けで、ロードバランサや複数台構成が必要になる さくらのクラウド 国内向けのまま、少しクラウドらしい柔軟性を持たせる
監査・統制・クラウド標準運用が必要 AWS 企業向けの周辺機能や標準運用を活用する
Microsoft製品・認証基盤との統合が重要 Azure 既存の企業ITとの親和性を優先する
分析・AI・Google系サービス連携が主役 GCP データ基盤・AI基盤としての意味を重視する
複数ノード運用、自動復旧、段階更新、独立スケールが重要 Kubernetes（必要に応じて各クラウドのマネージド構成も検討） Composeではなくオーケストレーションの価値が上回る段階で検討する

10. どれが上かではなく、どの段階にいるかで選ぶ

この選定順序は、各サービスの優劣を決めるためのものではありません。 案件の現在地、顧客の要求、将来の可能性、運用責任の持ち方に応じて、どの基盤が自然かを整理するための考え方です。

そのため、案件によっては最初からAWSが妥当なこともありますし、AzureやGCPが自然なこともあります。 一方で、日本の企業案件では、最初からそこまで大きな基盤を必要としないケースも多く、まずはVPSや国内クラウドで十分なことも少なくありません。

ビットオンでは、この順序を固定のルールというより、案件を整理するための実務的な判断フレームとして使っています。

11. まとめ

ビットオンのインフラ選定は、「最初から大きなクラウドを選ぶ」ことを目的にしていません。 まずはComposeレベルで閉じられるか、単一または少数サーバーで成立するかを確認し、必要十分な基盤から始めることを重視しています。

そのうえで、国内向けで柔軟性が必要ならさくらのクラウド、企業統制や標準運用が必要ならAWS、Microsoft系の統合が重要ならAzure、分析やAIが主役ならGCPというように、条件ごとに自然な選択肢を検討します。 また、複数ノード運用や自動復旧、段階的な更新、サービスごとの独立スケールが重要になる段階では、Kubernetesを使うべき局面かどうかもあわせて見極めます。

インフラ選定は、流行を追うことではなく、案件に対して適切な責任分界を選ぶことだと、ビットオンでは考えています。

12. ビットオンからのひとこと

ビットオンでは、Webアプリケーション開発、業務システム開発、Dockerベースの運用設計、Linuxサーバー構築、クラウド移行までを含めて、案件の現在地に合ったインフラ選定を重視しています。

「最初はどこまで小さく始められるか」「将来の拡張に備えて、どこまで移行しやすくしておくか」「国内案件としてどこまでシンプルに運用できるか」といった観点から、過不足のない構成を一緒に整理できます。

さくらVPS、さくらのクラウド、AWS、Azure、GCPのどれを選ぶべきか迷う場合も、案件条件を順に分解しながら、実装と運用の両面からご提案しています。

← ブログTOPへ戻る