カスタムインスタンスも検討
AWS、Azureとは違う? GCPインスタンスの選び方
「Google Cloud Platform」には幅広いインスタンスタイプがある。Googleクラウドが用意するインスタンスタイプの中から自社のワークロードに最適なタイプを選ぶためのガイドラインを提示する。
ワークロードは必ずしも同じではない。多くのCPUを必要とするワークロードもあれば、多くのメモリを必要とするワークロードもある。その点、Googleはクラウドインスタンスのさまざまなタイプを用意し、多くの選択肢を企業に提供している。
パブリッククラウドではリソースが事前に構成されるが、その選択肢が多すぎると、「選択のパラドックス」とも呼ばれる状況に陥る恐れがある。つまり品ぞろえが豊富になるほど、選ぶのが難しくなるというパラドックスだ。そして、選択を誤れば、パフォーマンスの低下やコストの増大など、重大な結果を招くこともある。
他のパブリッククラウドプロバイダーと同様、Googleの「Google Cloud Platform」では幅広いインスタンスタイプを用意してユーザーが選択できるようにしている。加えて、カスタムマシンタイプもある。本稿では、Googleが用意するクラウドインスタンスタイプの中から自社のワークロードに最適なタイプを選ぶためのガイドラインを提示する。
ワークロードのリソース要件と標準マシンタイプ
特定の用途に合わせて物理サーバのサイズを変えるように、Googleのクラウド仮想インスタンスを選択する場合、CPU、メモリ、ローカルストレージパフォーマンスの3つを基準に選択できる。一般に、コンピューティングとメモリの要件には相関関係がある。そのため、仮想CPU(vCPU)とRAMとの比率を固定して各インスタンスが事前構成されている。この構成は、Amazon Web Services(Amazon)の「Amazon Web Services」(AWS)やMicrosoftの「Microsoft Azure」(Azure)でも同じだ。ただし、CPUサイクルやメモリを多く必要とするワークロードもあるため、Googleのクラウドインスタンスには3つのタイプが用意されている。
- 標準マシンタイプ―vCPUごとに3.75GBのメモリ
- ハイメモリマシンタイプ—vCPUごとに6.5GBのメモリ
- ハイCPUマシンタイプ—vCPUごとに0.9GBのメモリ
Googleは共有コアマシンタイプも用意している。このタイプは複数のワークロードが1つのvCPUを共有する。だがこのタイプには、システムリソースが利用可能になると追加のvCPUを短期間使用できるバースト機能が備わっている。
vCPUの数は、2、4、8、16など2の累乗数で、最大32基まで選択できる。ただし、標準マシンタイプは1基から利用できるのに対し、ハイメモリマシンタイプとハイCPUマシンタイプで利用できるのは2基からになっている。Googleのn1 vCPU表記は、シングルコアハイパースレッドの総称で、この仮想CPUがIntelの2.6 GHzの「Intel Xeon E5(Sandy Bridge)」、2.5 GHzの「Intel Xeon E5 v2(Ivy Bridge)」、2.3 GHzの「Intel Xeon E5 v3(Haswell)」、2.2 GHzの「Intel Xeon E5 v4(Broadwell)」のいずれかで実装されることを表している。
Broadwellのシングルコアのパフォーマンスは第一世代のSandy Bridgeに比べて約20~25%高い。だが、Googleは周波数比に1.18:1を採用しているため、ほとんどのワークロードではBroadwell vCPUの方がわずかに速いだけだ。
ただし、ユーザーはインスタンスを構成する際に直接CPUの実装を選択できない。Googleでは地域ごとに使用できるシステムが異なるためだ。例えばGoogleは米国西部地域では最新のv4 Broadwellプロセッサにアップグレードしたが、米国中部地域では第一世代、第二世代、第三世代のCPUが入り交じっている。
Googleクラウドインスタンスのタイプを選択するユーザーは、事前にアプリケーションの要件を把握しておかなければならない。
大半のワークロードには標準マシンタイプが最も適している。だが小さなアプリケーション、リソース消費量がそれほど多くないアプリケーション、バックグラウンドアプリケーションには、共有コアマシンタイプのバースト機能を利用する方が適している。アプリケーションのプロファイリングを行わずに、vCPUとメモリの適切な組み合わせを選ぶのは難しい。だが、Googleは同社の「Google Stackdriver」を基盤とする推奨エンジンを用意している。このエンジンはシステムメトリックを収集して、こうした選択のガイダンスを生成する。
推奨ガイダンスは、直前8日間のデータを基に、以下の原則を使用して生成される。
- 大半の期間CPUの利用率が低いインスタンスでは使用するvCPUを減らし、利用率が高いインスタンスでは使用するvCPUを増やす
- メモリ使用率の低いインスタンスにはメモリが少ない構成を、メモリ使用率の高いインスタンスにはメモリが多い構成を選択する
Googleのカスタムマシンとローカルストレージ
Googleでは、特定のワークロードにどの標準構成も適さない場合に備えて、カスタムインスタンスタイプもサポートしている。カスタムインスタンスでは、vCPUの数を1~32基までの偶数で選択できる。併せて、メモリ比率をvCPUごとに0.9~6.5 GBまで0.25 GB単位で指定できる。
Googleクラウドインスタンスの各タイプは、永続ブロックストレージもサポートする。この永続ブロックストレージには、HDDまたはソリッドステートドライブ(SSD)を使用する。HDDでもSDDでも最大容量は64TBだ。各インスタンスはシングルコアに16個のディスクを割り当てることができる。8コア以上では最大128個のディスクを割り当てることができる。ディスクのパフォーマンスはサイズに応じて変化する。ただし、SSDはHDDに比べてインスタンスあたりのスループットが高く、読み取りIOPSで8倍、書き込みIOPSで67%、読み取り/書き込みIOPSで50~100%上回る。
一般に、読み取り数や書き込み数が少ないトランザクション処理ワークロードにはSSDを利用するメリットがあるが、コンテンツ配信ソフトウェアやリッチメディアソフトウェアのようなアプリケーションではこれまでどおりHDDを使用してもよい。Googleは永続ストレージを自動的に管理する。ただし、高いパフォーマンスを提供するために、ローカルに接続し、ユーザーが管理するiSCSI SSDやNVMe SSDもサポートする。
推奨事項
Googleは、クラウドインスタンスのさまざまな標準タイプと、CPU、メモリ、ローカルストレージをカスタマイズする機能を用意して、ユーザーに多くの選択肢を提供している。一般的には、事前構成されているインスタンスタイプのいずれかをそのまま使用し、Googleによるサイズ調整の自動推奨を使用する。運用経験を積み、CPUとメモリの非標準の組み合わせを必要とするパフォーマンスデータがそろうまでは、カスタムマシンタイプの使用は控える方が良い。
ただし、事前構成された2つのタイプの中間に位置する構成を必要とする場合は、カスタムマシンを使用すればコストを節約できる。分単位に課金されるのは標準タイプと変わらないが、カスタムタイプでは1時間当たりのメモリ使用時間とvCPU数に基づいて課金額が決まる。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分? 不足する対策を16項目でチェック -
事例
[Wrike Japan 株式会社] 世界的な家電メーカーが実践する「クリエイティブプロセス効率化」の方法とは? -
事例
[Wrike Japan 株式会社] 世界的テクノロジー企業に学ぶ、プロセス標準化とプロジェクト納品自動化の秘訣 -
事例
[Wrike Japan 株式会社] ソニー・ピクチャーズ テレビジョンに学ぶ、次世代サービスデリバリーのヒント -
事例
[Wrike Japan 株式会社] ソミック石川に学ぶ、ICT浸透後に直面した「工数管理」の課題と解決策
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
2
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
-
3
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
4
膨らむAIコストに歯止め GitHubのマルチモデルルーターは何が違うのか
-
5
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
6
エンジニアが選考を辞退する本当の理由 7割が隠す“面接の違和感”とは
-
7
Anthropicが明かす AIは入力データを「どこまで覚えているのか」
-
8
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
ライオンが挑む「守りのIT」脱却:Google Cloudで加速させるデータ駆動型経営
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド:25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
10
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー