ランニングコスト削減も可能？開発者が知っておきたいインフラ設計のポイント10選
- インフラ構築
- インフラ設計
- ランニングコスト削減
情報システムは企業において非常に重要な役割を担っており、システムの最適化により業務全体の効率化や、会社のイメージアップなどに繋がることも少なくありません。
しかし近年の経済状況もあり、システムに対しての投資コストは削減の対象となることが多いと思います。特に、購入すると長期間利用できるオンプレミスのサーバーとは異なり、クラウドサービスはOPEX(Operationg Expenses)の形式として毎月の利用コストが発生します。
そこでこの記事では、システムのコストの中でも大きな割合を占めるインフラレイヤーに着目し、その設計のポイントとコスト削減の工夫をご紹介します。
目次
インフラ設計の目的
そもそもインフラ設計は、ビジネスサイドの要件に合わせて必要なインフラストラクチャのリソースを整理し、環境構築の事前準備を行うことが目的です。サーバーの構成を決定するだけではなく、ネットワークやストレージといった環境全体のアーキテクチャを考慮する必要があります。
また、アプリケーションに必要な機能面だけではなく、パフォーマンス、セキュリティ、運用性、災害対策、事業継続性といった非機能的な要求も満たすことができるように設計を行います。そのため、インフラ設計の実施には幅広い分野における知識とノウハウが必要となります。
クラウドにおけるインフラ設計
近年、クラウドサービスの台頭により社内のシステムをクラウド上で構築することも少なくありません。しかし、従来のオンプレミス環境でのデータセンターにおけるインフラ設計とクラウド上のインフラ設計の考え方は大きく異ります。つまり、システムをクラウド環境に移行する場合には従来の設計思想を継承するのではなく、クラウド環境に適した新しい考え方に基づいて設計を行う必要があります。
例えば、従来のオンプレミス環境では、サーバーを一度購入すると基本的に次の更改時期までは同じリソースを利用することになります。もしリソースが追加で必要になったとしてもその調達にはある程度時間がかかり、すぐに追加することはできないため、ピークを見越してあらかじめ多めに用意しておく必要があります。
しかし、クラウド環境では全く逆の考え方で設計を行います。クラウドではリソースの追加や削除は非常に短時間で容易に行うことができます。加えて課金体系は従量課金であることから、できるだけリソースを利用している時間を少なくすることがコスト最適化に繋がります。そのためクラウド環境では、業務のピーク時に合わせて最大のリソースを保持し続けるのではなく、用意しておくリソースは必要最小限にとどめ、ピーク時にはサーバーを追加でオーダーしてリソースを拡張するといった考え方を設計に取り入れる必要があります。
また、クラウド環境ではIaaS環境のようにサーバーを用意するだけではなく、PaaSやSaaSのように必要な開発環境やサービスをインフラ部分を認識せずに利用する提供形態も存在します。いずれにせよクラウド環境の利用の際には従来の設計思想をそのまま適用することは得策でないことを理解することが重要です。
インフラコストの考え方について
コスト削減を考える上で重要となるインフラコストについて確認しておきます。
インフラコストに含まれる範囲とクラウドのコスト削減
インフラコストを考える際に、サーバーやネットワーク、ストレージの機器にかかる料金のみを計算してしまうことも多いと思います。しかしこれではインフラストラクチャ部分に発生する全てのコストを正しく認識することができず、結果としてコストがかさんでしまう可能性があります。
インフラコストには、例えば下記のように様々な項目があります。
- 機器搬入費
- 機器監視費
- 空調費
- ハードウェア購入費
- 備品購入費
- 設備構築費
- 機器設定費
- 機器構築費
- 工事費
- 電気代
- スペース費
- 設備保守費用
- 回線利用料
- 回線保守費
- サポート費
- 機器メンテナンス費
インフラコストを考慮する場合には購入するハードウェアの費用だけでなく、サービスの利用料金や運用の費用を加味した上で比較検討を行う必要があります。特にクラウド環境の場合は上記の様な費用があらかじめ含まれた上で価格決定がされているため、オンプレミスからの移行の場合に機器のみの費用と比較すると高く見える場合が多いです。比較する場合には比較対象をきちんと整理し、全体としてのコストがどのように変化するか確認しましょう。
イニシャルコストとランニングコスト
システムのコストはイニシャルコストとランニングコストの二種類に大別されます。
オンプレミス環境ではほとんどが機器購入として計上されるイニシャルコストであり、ランニングコストとして定常的にかかるコストは運用やメンテナンス等一部の費用です。クラウド環境ではその逆で、イニシャルコストはほとんどなく、サービス利用料としてほとんどの費用がランニングコストとして発生します。
そのため、例えば5年や10年といった長期的なスパンで利用するシステムであり、構成の変更やピーク性が全く無い業務の場合はオンプレミス環境が適していると言えます。反対に、キャンペーンなどで短期間のみ利用するシステムや今後の需要予測ができない新しいサービスなどはクラウド環境の利用を検討することでよりコストを抑えた形でシステムを構築できる可能性があります。
設計の流れ
インフラ設計のプロセスを簡単にご紹介します。
要件の確認
まずはビジネスを実現する上で必要なアプリケーションの構成を考え、その要件を確認します。要件には、アプリケーションの機能的な要件だけではなく、非機能要件も考慮する必要があります。
機能要件
機能要件とは、システムを実現するために必要となる機能に関する要件です。アプリケーションを実装する上でどの様な機能を満たす必要があるのかを考慮し、サーバーやネットワーク機器が持つべき機能を確認します。
非機能要件
非機能要件はシステムの性質に関する要件であり、機能要件以外の全ての要件です。例えば性能や可用性、セキュリティ等が項目としてあげられます。
アーキテクチャの策定
要件の洗い出しが完了した後は、システムを実現するための全体のアーキテクチャを検討します。必要となるコンポーネントや、接続経路など、それぞれの要件を満たすように構成していきます。
機能要件から機器の種類を選定するだけではなく、非機能要件に応じて、バックアップソリューションの導入や、冗長化、災害対策環境の実現、運用管理手法の確立、セキュリティに対する対応等、必要となる項目を全て確認する必要があります。
ソリューショニング
全体の構成が決定したら、必要となる各コンポーネントを選定し、ソリューションとして落とし込んでいきます。利用するOS、ミドルウェア、ソフトウェア等の選定を行い、各機能の連携により機能要件や非機能要件が充足できることを再度確認します。
また、場合によってはサーバー上に導入するだけでなく、外部のサービスと連携することにより一部の機能をアウトソースすることも可能です。ソリューションを最適化するためには様々な可能性を考慮し、各種要件だけでなく、コストや運用性など、あらゆる観点から検討する必要があります。
リソースの決定
最後に、キャパシティープランニングを実施し、リソースのサイズを確定します。キャパシティープランニングとは、現在の使用率や今後の拡張性などを分析し、必要となるリソースの大きさを予測することです。
既存のシステムをすでに運用していてある程度需要の予測が可能な場合や、利用するユーザーの数が確定的で使用量に増減がない場合などにはある程度正確な値を算出することができると思います。しかし、全く新しいサービスの展開時など、需要の予測が困難な場合には、クラウドサービスの利用も合わせて検討すると良いでしょう。
小さな環境から開始し、必要な場合にのみ追加でリソースを拡張することで、過剰なリソースを注文するリスクを低減することが可能です。
インフラ設計で重要なポイント
上記の前提を踏まえた上で、実際にインフラ設計を行う際に重要となるポイントを解説していきます。
ポイント1: 現実的な非機能要件を意識する
非機能要件は、パフォーマンスや可用性、セキュリティに関する要件であり、機能要件以外の要件を指しています。もちろん非機能要件は全く考慮しないことはできませんが、ビジネス上の要件を実現する上で必要となる現実的な要件を設定しなければ意味がありません。
例えばパフォーマンスに関して、「画面上でユーザーに対するレスポンスは2秒以内とすること」といった非機能要件をよく目にします。当然ユーザーに対するレスポンスが早ければ早いほどより良いユーザー体験を与えることが可能ですが、この要件は現実的ではなく、正確に要件を満たすのは困難です。なぜなら上記の記述では、あらゆる種類の処理において全ての期間でレスポンスが2秒以内であることを達成しなければならず、想定しているよりもハイエンドな機器を導入する事になる可能性があります。
非機能要件を策定する際には、処理の種類や前提条件、達成条件といった種々の条件を考慮した上で決定することをおすすめします。例えば「チャット画面においてユーザーが文書を入力してから発生するWebサーバーの処理時間において、2秒以内を達成すること。ただしピーク時には3秒以内を目標とし、90%以上のトランザクションが時間内に処理を完了することを達成の条件とする」といった形で条件について詳細化することでビジネス上の目標を達成しつつ、必要最小限のリソースの導入により実現することが可能となります。詳細化の方法については後述します。
ポイント2: 非機能要件とコストのトレードオフ関係を理解する
また、非機能的な性質の向上とコストがトレードオフの関係にあることを理解することが重要です。パフォーマンスや可用性は、基本的にはコストをかければかけるほど向上させることが可能です。しかし、ビジネス上の観点から見て本当に要求している性能や可用性が必要であるかを確認する必要があります。
例えば障害時の復旧基準として、RTO(目標復旧時間)、RPO(目標復旧時点)を考慮すると思います。当然短く設定することで業務内容のリカバリーは容易になり、損失を最小限に抑えることが可能です。
しかし、短時間での復旧はシステムの面から見ると容易なことではありません。データの常時レプリケーションやリアルタイムバックアップなど、インフラだけでなくミドルウェアやソフトウェアの機能と連携した上で構成を考慮する必要があり、コストが大きく増大する可能性もあります。そのため障害時の復旧基準は、障害が発生した状況や、継続する必要がある業務内容の確認を行い、具体的な根拠に基づいて設計する必要があります。
ポイント3: PoCを実施する
インフラのキャパシティプランニングや、非機能要件の策定において重要なのがPoC(Proof of Concepts)を行うことです。PoCとは概念実証のことで、システムの設計においては実環境に検証環境を用意し、状況を再現することで各機能や非機能について検証を行うことを指します。特に既存のシステムを別環境に移行する場合には、実際に要件を実現するための機能を充足することができるのか、どの程度のパフォーマンスが出るか、障害時や災害時のスクリプトが稼働するか等、実際の環境で検証しなければわからないことが非常に多く、検証を実施することが必要不可欠です。
検証の実施によりあらかじめ問題となる箇所を特定し、実環境の利用時に解決しておくことでシステム利用者の満足度を向上させることに繋がります。
ポイント4: 仮想化によるサーバー統合
現在では一般的な手法となっていますが、仮想化ソフトを利用することで複数のサーバーを統合し、ハードウェアの台数を削減することができます。前述の通りインフラコストには多くの項目があるため、1台のハードウェアが不要となると機器のコストだけではなく、設置費用や保守費用など様々なコストを削減することができます。
サーバー統合を実現する場合に、物理CPUのコア数と仮想CPUのコア数の割合が重要となります。ハイパーバイザーの特性にもよりますが、物理CPUよりも仮想CPUを多めに載せるオーバーコミットが可能ですので、使用率や各サーバー機器の性能などを考慮し、できるだけ効率的に集約できるように考慮しましょう。しかし一方で、1台の物理サーバーに多くのサーバーを載せすぎるとそのサーバーの障害時にシステムに与える影響が大きくなるため、バランスが重要です。可用性を高めるためにはいくつかの物理サーバーに分散させて配置する必要があります。
また、仮想化ソフトであるハイパーバイザーにはVMwareやHyper-V、KVMなど様々な種類が存在します。それぞれに特徴がありますので、自身の利用するOSやシステムの要件に合わせて検討しましょう。
ポイント5: 信頼性と可用性の違い
信頼性とは障害の発生のしにくさのことです。機器が壊れることなく継続的に利用できる時間の指標となります。システム全体の利用しやすさを考慮した場合、信頼性だけを考えるのではなく、可用性を考慮する必要があります。可用性とは、システムやサービスを利用できる時間の指標であり、利用者の観点からは可用性が重要となります。
例えば信頼性がそれほど高くない、つまりよく故障する機器を利用していたとしても、複数台を並列で並べ、同時に利用することで冗長化を実現し、ユーザーから見てサービスを継続できる場合もあります。物理的な機器はいつか故障が発生します。そのため、故障が発生してもサービスを継続的に利用できる仕組み作りが重要となります。
ポイント6: 複数の外部サービスを効果的に組み合わせる
ガバナンスや内部統制の観点から、1つの環境やサービスにシステム全体を統合し、あらゆる機能を実現する構成を考えることもあると思います。しかし、1つの環境に全ての機能を実装することが最適ではない場合も存在します。その場合には利用したい機能を得意とする外部サービスやクラウドにアウトソースすることでコスト効率化やリスク低減を図ることができます。
近年ではマルチクラウドやハイブリッドクラウドの考え方が一般化しており、各クラウドベンダーでもオンプレミスや他クラウドと連携できる機能を備えたサービスも提供されています。PaaSやSaaSといった形態を利用することで運用負荷の低減が実現できる場合もありますので、大きなサーバーに仮想サーバーを大量に載せてあらゆる機能を実現する、という選択肢だけではなく、各機能ごとの特性から最適なサービスを考慮する必要があります。
ポイント7: 新しい技術が最適とは限らない
IT技術の進歩は目覚ましく、日々新しい技術が生み出されています。コンテナ仮想化やサーバーレス、ディープラーニングといった革新的な技術を自身のシステムで利用することを検討する場合も多いと思います。
しかし、自身が想定しているビジネス上の価値が必ずしも最新の技術により実現できるとは限りません。場合によってはオンプレミスでサーバーを購入し、仮想化せずにそのまま利用する形態も考慮に入れ、コストやリスクの観点から最適な構成を考慮することが重要です。
ポイント8: 拠点間接続の方法と帯域
インフラ設計はサーバーのキャパシティプランニングだけではなく、ネットワークにおける考慮も必要です。スイッチやルーターといったネットワーク機器や、それらを接続する回線もインフラ設計の大きなポイントとなります。
特にWANをまたぐ拠点間の接続を考えた場合、インターネット接続に加えて、専用線による接続も考慮する必要があります。専用線の接続には拠点間のルート交換の設定はもちろん、物理的な回線や機器の準備が必要となりますので、入念な調査が必要です。
また帯域に関して、回線の帯域を太くすればするほど回線速度が早くなるわけではありません。回線の速度にはパケットの経路や処理の分散など、アプリケーションのレイヤーで考慮することも多く、帯域を十分に使い切れていない場合も多いと思います。帯域の設計にはアプリケーションの実装も含めた実環境での検証を行うことをおすすめします。
ポイント9: IPアドレッシングの考慮
また、ネットワーク設計においてはIPアドレスの割当も重要となります。特にWANをまたいで複数の環境を利用する場合には、IPアドレスのセグメントをどのように設計するかが重要となります。同時に同じセグメントを利用するにはL2で延伸する必要があります。
また、データセンター側の制約により重複が避けられない場合にはNATやIPエイリアス、ネットワークの仮想化などを利用して回避する必要があり、ネットワーク機器の選定や設計後の構築、運用に大きな影響が生じるため、インフラ設計段階でよく考慮しておくことが重要です。
ポイント10: 運用手法の踏襲と変更
運用には機器やネットワークの監視、ログの検出、環境の管理等、様々な項目が存在します。クラウドを利用する場合は専用のサービスが用意されている場合も多いため、利用を検討すると良いでしょう。
しかし、あらゆる機能を提供しているサービスは存在しないため、要件に合わない場合もあると思います。その場合には要件を満たすソフトウェアを構築して利用することも考えられますが、想定している運用手法の変更を検討しても良いと思います。各サービスにおける機能の充足とコストを比較し、必要不可欠な機能の選定を実施しましょう。
まとめ
この記事では、インフラ設計においてそのプロセスと重要な考慮点の一例について簡単に解説しました。インフラ設計にはまだまだ多くの項目があり、検討を続けることでコスト削減やリスク低減が実現できることも多いです。自身が目指すビジネス上の価値を実現することのできる最適な構成を考慮するために必要な手順となりますので、是非各ポイントを熟考し、設計の参考にしてみてください。
弊社トップゲートでは、Google 技術を利用したアプリケーション開発に関するコンサルティングサービスを行っております。ぜひ詳細はリンク先にてご確認ください！
詳細はこちら
弊社トップゲートでは、Google Cloud (GCP） 利用料3%OFFや支払代行手数料無料、請求書払い可能などGoogle Cloud (GCP）をお得に便利に利用できます。さらに専門的な知見を活かし、
- Google Cloud (GCP）支払い代行
- システム構築からアプリケーション開発
- Google Cloud (GCP）運用サポート
- Google Cloud (GCP）に関する技術サポート、コンサルティング
など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。
Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！
Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。
お問合せはこちら
メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite） 、TOPGATEの最新情報が満載！
関連記事
Contactお問い合わせ
Google Cloud / Google Workspace導入に関するお問い合わせ