はじめに
サーバーは問題なく動いているのに、コストは増え続けている。ArcGIS Enterprise を運用するのは、どうしてもお金がかかるもの？——そんな悩み、一度は感じたことはありませんか？
こんにちは。ESRIジャパンのハン サンウォンです。
私たちのチームは、毎日 AWS コンソールを見ながらお客様の ArcGIS Enterprise 環境を点検し、安定運用とあわせて、パフォーマンスとコストの両面を最適化する業務を行っています。
今回のブログでは、以前社内ワークショップでご紹介した内容をもとに、ArcGIS Enterprise を AWS 上で構築・運用する過程で、今日からすぐに適用できるクラウドコスト最適化のポイントをいくつかご紹介したいと思います。
クラウドコスト最適化というと、新しい技術を導入したり、問題なく動いているワークフローを作り直したりといった、アーキテクチャの変更をイメージしがちですが、実際にはそう簡単ではありませんよね。実は、クラウドのコスト管理の出発点は、不必要な無駄を減らすことにあります。
このブログでは、コスト削減のための革新的な新技術を紹介するというよりは（そんなものがあるはずもないですし！）、すでに使っている環境の中で不必要に消費されているコストを見つけ出し、パフォーマンスを維持したまま、どうすれば削減できるかに焦点を当ててみたいと思います。
ポイント1：インスタンスは「大きく」ではなく「合わせて」選ぶべきです。
足のサイズや日常のパターンによって合う靴が変わるように、ArcGIS Enterprise のインスタンス選びも、結局は用途によって変わります。
（ソース：Amazon EC2 インスタンスタイプの命名規則 - Amazon EC2）
EC2 インスタンスは Series / Generation / Size / Architecture などの要素で構成されています。
しかし、実際の運用現場でよく見かけるパターンは、「とりあえず大きなインスタンスを1台用意して、そこにすべての ArcGIS Enterprise コンポーネントを入れる」というものです。
確かに設計においては便利な方法ではあります。ただし、運用においては課題もあります。大きなインスタンスが常により良いパフォーマンスを保証するわけではないからです。
構成に関しても、ArcGIS Enterprise は多様な構成をサポートしていますが、詳しくお話しすると長くなってしまうため、ESRIジャパン Web サイトの技術ドキュメントをご参照いただければ幸いです。
→ リソース | ArcGIS Enterprise | ESRIジャパン株式会社
サーバーにリクエストが来たとき、利用可能なシステムリソースに余裕がなければ待ち時間が発生し、待ち時間が発生すればパフォーマンスが低下します。そのため、常に一定以上の余裕あるシステムリソースが確保されているかをチェックすることが、インスタンス選びにおける重要なチェック項目となります。
1) ArcGIS Enterprise は一般的に「CPU」よりも「メモリ」が重要です。
ArcGIS Enterprise にはさまざまなユースケースがありますが、代表的なものは、ブラウザを通じてサーバーに保存されている空間データや地図を閲覧することではないでしょうか。
この過程では、大量の空間データをディスクから読み出してメモリに格納し、クライアントからのリクエストに応じてデータを表示するという処理が行われます。
つまり、大量の空間データをメモリ上に展開しておく必要があるため、ほとんどの ArcGIS Enterprise 環境では、CPU よりもメモリの要件が重要になるケースが多いのです。
そのため、一般的には Compute Family（C）よりも Memory Family（R）を選択する方が有利なケースが多くなります。
2) AMD インスタンスは、すぐに適用できるコスト削減ポイント
CPU アーキテクチャを選ぶ際、どうしても慣性的に m5 や t3 など Intel ベースを選びがちですよね。しかし、ArcGIS Enterprise は AMD アーキテクチャも Intel と同様に公式サポートしています。そして、AMD ベースのインスタンス（m5a や t3a など）は Intel ベースと比べて、同等のパフォーマンスでより安価な場合が多いです。
→ （参考）Does Esri Support AMD Processors with ArcGIS Products?
（ソース：Amazon EC2のコンソール）
実際にT3インスタンスファミリー、東京リージョンの場合、Windows Serverは約 7~8%、Linuxは約10%のコスト削減が可能です！
従来と同じインスタンスを選択・維持することは「安全な選択」ではありますが、実際には不必要なコストが発生している可能性もあるのです。
ポイント2：「つけっぱなしで忘れたコスト」を排除します。
EC2 インスタンスは ArcGIS Enterprise をデプロイして 24/7 運用するケースも多いですが、高性能環境やテスト環境が必要なときに一時的に起動して活用するケースも少なくありません。EC2 は GPU の有無を含めて高性能なほど高価であり、基本的に使用した時間分だけコストが発生します。つまり、使っていなくても起動していれば課金され続けます。
高性能 EC2 インスタンスを一時的に利用するとき、あるいはテスト/開発環境で最ももったいないことは何でしょうか？いろいろあるかもしれませんが、最もよくあるケースは、「つけたまま退社してしまうこと」ではないでしょうか。
特に ArcGIS Pro の実行環境にはより注意が必要です。ArcGIS Pro は EC2 を含む仮想環境をサポートしており、GPU を含む高性能インスタンスを要求します。そして G4dn 〜 G6 などの高性能 GPU 搭載インスタンスは、汎用インスタンスである T シリーズや M シリーズと比べてコストがかなり高くなります。
AWS はこれを軽減するために、Instance Scheduler on AWS というソリューションを提供しています。このソリューションを活用すれば、ArcGIS Pro が動作する EC2 や RDS を、タグとスケジュールを使って自動的に起動・停止（または停止のみ）を制御できます。
（ソース：Instance Scheduler on AWS）
社内でも ArcGIS Pro の検証環境において毎日 17:30 に自動停止を運用しており、G4dn ファミリーの検証環境が不必要に週末や業務時間外に稼働し続けないよう管理しています。これにより、運用ミスによるコスト増加を抑えることができます。
ポイント3：インスタンスだけ「合わせて」設定していませんか？
ーー ストレージも「合わせて」設定すべきです。
ストレージは、コンピューティングコストと比べると見落とされがちな領域です。しかし、爆発的にコストが増加しうる領域でもあります。
1) gp3 は基本的により経済的で柔軟です。
EBS の最新 SSD 世代である gp3 は、gp2 と比べて GiB あたりのコストが約 20% 低く、前世代の gp2 とは異なり、容量とは別にディスクのパフォーマンス（IOPS およびスループット）を独立して調整できます。
このため、gp2 では IOPS を確保するためにディスク容量を過剰に増やすケースがありましたが、gp3 ではパフォーマンスと容量を分離して設定できるため、こうした構造的な無駄を削減できます。
2) ストレージのパフォーマンスも状況によって異なります。
ディスクのモニタリングと管理はサービスのボトルネックを防ぐために必須ですが、パフォーマンスに影響を与える要素は状況によって異なります。
- リアルタイムデータ収集などランダムアクセスが多いワークロードでは IOPS が重要です。
- 大容量データ処理やバックアップ/リカバリ時には スループット が重要です。
（ソース：Amazon EC2のコンソール）
gp3 の場合、ブログ執筆時点ではデフォルトで 125 MiB/s のスループットが提供されています。しかし、WebGISDR リカバリなどの作業ではスループットが上限に達し、キュー待ちが増加するケースがあります。実際にこのようなケースで IOPS とスループットを調整し、10% 以上リカバリ時間を短縮した事例があります。
注意すべき点として、パフォーマンス値を上げれば当然コストも増加するため、CloudWatch などを活用し、実際のモニタリングに基づいて調整し、必要以上に割り当てないようにする必要があります。
なお、EBS ディスク容量は一度拡張すると縮小できませんが、EBS のスループットと IOPS は自由に縮小可能です。これにより、バックアップ/リストア作業時には通常よりスループットを多めに割り当ててパフォーマンスを高め、所要時間を短縮し、通常時には元に戻すことができます。
ポイント4：S3 は容量と「保存方法」でコストが変わります。
基本的に S3 にデータをアップロードすると S3 Standard に保存されます。これは即時アクセスが可能で高い耐久性を提供しますが、保存単価が高くなります。
一方、即時アクセスが不要なデータについては、より安価な別の保存方法を検討する余地があります。さらに、アクセスパターンが不明確だったり変動するデータについては、その保存方法の選択をクラウドに任せることもできます。
- 頻繁にアクセス: Standard
- たまにアクセス: IA (Infrequent Access)
- 長期保管: Glacier
- パターン不明確: Intelligent-Tiering
一方で、Glacier のような低価格クラスは保存コストは下がりますが、アクセス時に追加料金が発生し、復元が完了してアクセス可能になるまで時間がかかることがあります。（圧縮を解凍するのに時間がかかるイメージです。）
S3 と連携できる ArcGIS Enterprise の構成要素は、ラスターデータ、Object Store、マップキャッシュ、WebGISDR バックアップなど様々です。それぞれのデータ特性に応じた保存戦略を適用することで、 バックアップ、ログ、古いデータのアーカイブは Standard ではなく、保存単価の低いストレージクラスを検討できます。
例えば、頻繁には使わないものの、必要時に即時アクセスが必要で、元データが別にある派生データには、S3 One Zone-IA が良い選択肢となり得ます。
ポイント5：モニタリングツールとソリューションを活用します。
当たり前のことですが、現在のシステムの状態を把握できなければ、「合わせて」調整することもできません。平時から AWS CloudWatch や AWS Compute Optimizer といったサービスを積極的に活用し、現在のシステムの状況を把握することが重要です。
たとえば、AWS Compute Optimizer は過去の使用パターンを分析し、現在のインスタンスが過剰に割り当てられているかどうかを自動的に判断し、適切なインスタンスタイプを推奨してくれるほか、アタッチされていない、あるいは使用率の低い EBS リソースなども検出してくれます。「不必要な無駄」をデータに基づいて検証できるツールです。
ESRIジャパンも、ArcGIS Enterprise のモニタリングに特化した ArcGIS Monitor という製品をサポートしており、インフラ全体はもちろん、個々のサービス単位の状況を把握できます。これにより、サービスレベルでの可視化と最適化が可能になります。
→ （製品ページ）ArcGIS Monitor | ESRIジャパン株式会社
- パフォーマンス、状態、システムの使用状況を監視
- ステータス、使用状況、リソース使用率に関するデータと情報を収集できます。
- 情報やデータを分析、可視化し、適切なリソースの割り当てやパフォーマンス問題の調査を支援します。
まとめ
クラウドコスト最適化には、残念ながら「銀の弾丸」と呼べる正解はありません。
しかし、現在の運用環境を改めて見直し、小さなことから実践していく行動が、今月の請求書から長期的なソリューションコストの削減につながると考えています。
ArcGIS Enterprise は単なるシステムではなく、組織の GIS 業務を支える基盤プラットフォームです。プラットフォームに常にデータが蓄積されていくことが重要であるように、増え続けるデータと需要をどう管理するかも同じくらい重要です。
これからも、こうした観点から実際の運用で得た経験を少しずつ共有していきたいと思います。ご質問やご意見がありましたら、ぜひお気軽にお寄せください。
このブログが、皆さまがそれぞれの環境で運用されている ArcGIS Enterprise のコスト最適化のきっかけになれば幸いです。
関連リンク
