202407版

HinemosでGoogle Cloud運用を実現するメリット

NTTデータ先端技術株式会社© 2024 NTT DATA INTELLILINK Corporation

INDEX
1.
2.
3.
4.

運用管理における課題とFAQ Google Cloud編
運用管理における課題とFAQ パブリッククラウド編
運用管理における課題とFAQ ハイブリッドクラウド編
appendix© 2024 NTT DATA INTELLILINK Corporation2

1
運用管理における課題とFAQ Google Cloud編© 2024 NTT DATA INTELLILINK Corporation© 2024 NTT DATA INTELLILINK Corporation3

監視Google Cloud環境の監視はインフラ・専用リソースの監視が必要
Google Cloud環境の監視の課題

モニタリングサービスと連携したシステム監視

HinemosによるGoogle Cloud環境の統合管理
Hinemosを導入することで、ユーザが作りこみをする必要なく、Google Cloudの監視に必要な機能の連携を実現します。
ターゲットシステム

Google Cloud環境の監視には Cloud Monitoringは必要です。しかし、それだけでは実際の運用要件を満たせず、何かしらの監視ツール・サービスとの連携/作りこみが必要になります。
Cloud Monitoringの必要性
・Cloud Monitoring経由で取得が必要なリソース値
Google Cloudの各種PaaS
Persistent Disk (ネットワークストレージ)

Cloud Monitoringの課題
・保存期間が6週間（一部は24か月）
・業務カレンダとして連携した監視/通知抑制
・業務層の監視(Webシナリオ監視等)
・一部OS上のリソース値取得は作りこみ

Google Cloudというプラットフォームの監視
Google Cloud環境はクラウドサービスとして提供されたインフラですが、このインフラ・サービスが正常に動作していることを監視する必要があります。これはGoogle Cloudの外部から監視する必要があり、Google Cloudの提供するGoogle Cloud Serivce Healthから独自で監視する必要があります。

監視

一般的な監視機能

Hinemos

Google Cloud Serivce Health

CloudMonitoring

Google Cloud
Service Health

Hinemosの提供する監視機能© 2024 NTT DATA INTELLILINK Corporation4

運用自動化

変化する環境に自動対応する構成管理機構が重要Hinemosによる運用自動化

Google Cloud環境の運用自動化の課題
環境変更への追随
柔軟なリソースコントロールができるGoogle Cloud環境においては、その環境変更による運用コストの低減が課題になります・Compute Engineインスタンスの検出(初期構築/自動スケーリング)
・リージョン、ゾーンへのマッピング(ロケーション)
・VPC、サブネットへのマッピング(ネットワーク構成)

HinemosにGoogle Cloudへの接続情報を登録すると、Google Cloud上のComputeEngineインスタンス情報を取得し、プロジェクト、リージョン、ゾーン、VPC、サブネットの単位で自動グルーピングします。運用開始後も自動追尾して、環境変更時に伴う運用操作は必要ありません。
自動構成管理

運用対象の構成把握に運用コストが掛かる

運用者

監視・ジョブの運用自動化
自動検出した対象について、対象別に監視・ジョブを自動的に開始する仕組みが必要です。
これを実現するには次の３ステップの自動化が必要です。

①自動検出

②識別

自動スケールや計画的な機器増設による仮想マシンの変更は、オペレーションミスを避けるため、自動検出の仕組みが必要です。

新規仮想マシンを検出した際に、何の属性(OSやミドルウェア)を持ったものかを識別できる仕組みが必要です。

③監視・ジョブ
開始
仮想マシンを識別した後にようやく属性にあった監視やジョブを設定することができます。

Compute Engineインスタンスにメタデータ情報を付与することでHinemosは自動的にその属性を識別し、属性に合わせたグルーピング(スコープ割当て)を行います。グループ別の監視やジョブ定
義を事前定義することで、環境変更に影響なくLinuxWindows監視・ジョブの運用自動化が可能です。
メタデータを使った自動識別Compute Engine
インスタンスWebサーバスコープ割当ルール

＋

検出

識別

APサーバ

メタデータ情報

DBサーバ© 2024 NTT DATA INTELLILINK Corporation5

リソース制御

業務フローの中でGoogle Cloudリソース制御が重要

Google Cloudのリソース制御の課題
自動スケーリングの課題
自動スケーリングは非常に有用なソリューションですが、スケールイン・スケールアウトのポリシーの条件設定が難しく、予期せぬタイミングでポリシーが発動するかもしれません。また、条件によっては、試験ができないケースがあります。

Managed Instance Group追加

ポリシー設定はどうすれば？
試験はできるの？

リソース制御と業務連携
HinemosではCompute Engineインスタンスの起動・停止処理をGUIから簡単にジョブとして登録する機能があります。これにより、システム閉塞・開放といった、リソース制御を伴うことでコスト削減を実現するクラウドのメリットについて、Hinemos単独で作り込をすることなく実現することができます。

夜間
止めたい

削除

インスタンスのコントロールをジョブを専用画面で簡易に作成

運用者

リソース制御と業務連携
Compute Engineインスタンスの起動・停止のコントロールは単純に実施すればよいものではなく、業務・システムと連動して行われるべきです。そのため、システム閉塞・開放といった簡単な処理でも、業務フローと連携する機能が必要になります。
どうやって連携する？

単純な起動・停止は可能

運用者

通常の運用管理製品
システム
閉塞マシン
停止マシン
起動

システム開放・スケジュール起動・カレンダ制御

LB閉塞

AP停止

ComputeEngine停止

バックアップ

業務処理のフロー管理は可能© 2024 NTT DATA INTELLILINK Corporation6

参考情報HinemosによるGoogle Cloud使用料金の削減
Google Cloudの(主にCompute Engineの)使用料金削減のポイントはCompute Engineの起動時間
Compute Engine使用料金の仕組み(概算) = インスタンス数 × インスタンスタイプ × 時間
Google Cloud使用料金の削減にHinemosを使用するメリット①簡易なGoogle Cloudリソースコントロール機能
簡易なGUI操作でCompute Engineの起動停止処理をジョブフローに組み込めます②業務閉塞・開放と連動したGoogle Cloudリソースコントロールのスケジュール管理
業務処理連動のジョブフローを要件に合わせて実行することができます③業務カレンダを使用した停止中の監視抑止(監視機能との連動)
業務停止中には業務の監視を停止するなど、業務カレンダの連携が簡単に行えます

Compute Engineインスタンス起動時間制限によGoogle Cloud料金削減効果
・土日を停止できれば70％

月-金→ 5/7

・さらに営業時間を8時～24時に限定すれば50％

月-金&8:00-24:00→ (5/7)x(16/24)© 2024 NTT DATA INTELLILINK Corporation7自動化 運用自動化には双方向の連携が必要
クラウド環境との双方向連携の課題

Hinemosによる双方向連携

クラウド内の連携
用途に応じて、クラウド導入においてクラウド側に構築した自動化の仕組みと、運用管理ソフト上にある自動化の仕組みの両方が存在するケースが多々あります。クラウド移行のケースの場合は、主に既存のジョブ定義になります。これらの、相互連携が全体的な自動化・効率化に重要になります。

クラウド側の自動化

Hinemosはクラウド上で発生した汎用的なイベントを受けとり、指定のジョブフローを起動する事ができます。また、Hinemosより監視や業務ジョブの中から、クラウド側に汎用的な通知メッセージを送信し、指定の処理を起動する事ができます。

マルチクラウドに対応した双方向連携

運用管理ソフト側の自動化
クラウドA

運用管理ソフト

クラウドB

業務ジョブフロー・PaaSのアプリケーション
・サーバレスのアプリケーション

アプリ2

ジョブ2

ジョブ1

ジョブ4

アプリ1

ジョブ1

アプリ3

マルチクラウドの連携

連携

単独のクラウドだけではなく、マルチクラウドで組んだシステム間の連動をどのように実現するかも大きな課題です。

どうやって連携しよう

クラウドA

CloudFunction

連携
業務ジョブフロージョブ2

Pub/Sub
ジョブ3

クラウドB
通知の集約とクラウド間のブリッジによりシームレスな自動化を実現

アプリ1

アプリ2

運用者

アプリ3

アプリ4

注1） Cloud Functionからの連携は、カスタムトラップ監視設定のサンプルを提供© 2024 NTT DATA INTELLILINK Corporation

8

FAQ

Cloud MonitoringがあるのにHinemosは必要？

性能値のカバー範囲

営業日・営業時間の判断

Cloud Monitoringは、・PaaSのため必須
・一部OSの性能値はエージェントの導入、指標のユーザ定義が必要

Cloud Monitoringは、・営業日や営業時間といった業務カレンダと連携した監視は作りこみが必要

Cloud Monitoringは、・バーストして発生する通知の抑制や集約には別の機構と連携した作りこみが必要

Cloud Monitoringは、・メトリクスの保存期間が6週間（一部は24か月）・長期保存にはエクスポートなどの作りこみが必要

一般の運用管理製品では、・OS上の性能値は得意・サービス監視も得意

一般の運用管理製品では、・営業日・営業時間に性能値が取れていないと異常と判断可能

一般の運用管理製品では、・瞬間的な異常や、バーストして発生する異常通知を抑制可能

一般の運用管理製品では、・ディスク容量次第で設定可能

業務カレンダによる判断が必要

通知する際の不要なメッセージ抑制が必要

Cloud Monitoringも運用管理製品も必要

通知の抑制

データの保存期間

年単位の保管も当たり前なので対策が必要

Hinemosでは？
Cloud
Monitoringとシームレスな連携ジョブが具備する
高度なカレンダ

メッセージ抑制可能な通知機能© 2024 NTT DATA INTELLILINK Corporation

任意の期間でデータ保存
9

2
運用管理における課題とFAQ パブリッククラウド編© 2024 NTT DATA INTELLILINK Corporation

10

運用管理の可用性

運用管理マネージャのHA構成をシンプルに運用管理の可用性の課題

Hinemosによるクラスタ機能
Hinemosでソフトウェアとして可用性構成を実現します（ミッションクリティカル機能）

可用性の要件の違い

Hinemosミッションクリティカル機能

オンプレミス環境では物理サーバの障害を考える必要がありましたが、仮想化環境やパブリッククラウド
環境では、考えるべき要件が異なります。その条件により、運用管理製品の対応有無を確認するというフェーズが必要になります。
仮想化環境

オンプレミス環境

・仮想OSの障害・ホストマシンの障害
・データストアの障害
クラウド環境・仮想OSの障害
・データセンタ障害

・サーバ障害オンプレミス環境で構築してきたクラスタ構成は、パブリッククラウド上で同様な構成を取ることが非常に難しく、クラウド毎で提示される「ベストプラクティス」を実装する必要があります。

FIP(FloatingIP)の問題

共有ディスクの問題
様々な制約

運用管理製品の問題

Hinemos
マネージャ

レプリケーション

クラスタリングソフトや共有ディスクは不要
環境非依存/FIP不要

クラスタ構成の様々な制約

クラスタミドルの問題

Hinemosマネージャ

死活監視（ハートビート）

オンプレミス、仮想化、クラウド環境で同じ構成で可用性構成が組めます。構成がシンプルのため、設計・構築時のSE/CEコストの削減が可能です。FIPを使用せず可用性構成を組めます。
ロストなしの監視
クラスタミドルを使用しない独自な構成により、syslogやsnmptrapもロストなしで監視ができます。

ワンストップ保守
ソフトウェアで実現する可用性構成のため、障害発生時の対応がHinemosサポートに投げるだけ、のワンストップ保守が実現できます。

ジョブ管理の冗長化

クラウド黎明期の課題であるジョブ管理マネージャの可用性構成が簡単に実現できます。

※参考情報（クラウドにおけるクラスタ構成の様々な制約）に詳細を記載© 2024 NTT DATA INTELLILINK Corporation

11

参考情報

クラウドにおけるクラスタ構成の様々な制約
運用管理の可用性の課題

共有ディスクの問題

可用性の要件の違い

目的の障害に対応できるか何を利用するのか目的の障害に対応できるかクラウドミドルはセンシティブな製品です。
目的のクラウドに対応しているか確認が必要です。

クラウド上のHAはデータセンタ障害などオンプレミス構成とは違う範囲の障害も検討が必要です。

クラウドサービスでは目的により選択肢があります。どれを採用するかが製品により変わります。

クラウド上のHAはデータセンタ障害などオンプレミス構成とは違う範囲の障害も検討が必要です。

運用管理製品の対応
クラスタミドルの対応〇？

NWセグメント障害(VPC等)〇or×

データセンター障害(AZ等)〇？

ブロックストレージ(EBS等)〇？

DBサービス(RDS等)FIP(Floating IP)の問題〇？

NWセグメント障害(VPC等)〇？

〇？

データセンター障害
(AZ等)

〇？

運用管理製品の問題

AWSの問題Azureの問題

組み合わせサポート

構築・障害時解析の簡易さ

VPC PeerやDirect Connectを跨ぐ環境ではFIPは利用できないため、古典的なHA構成がとれません。

AzureではIP付け替えにAPIコールで何分も必要なので、ロードバランシング方式が推奨されています。(SI対応)

各課題のため未だにクラウド対応が遅れてます。
単機能製品の場合は、ここでサポート有無を判断する必要があります。

一般に製品の範囲だけで解析が困難な複雑な構成になるため、初期構築も障害発生時の解析も困難です。

Direct Connect間のFIP

×

ロードバランサ方式推奨

時間が掛かる

クラスタミドルクラウド依存SI構築が発生

セッ製ト品で数判
断共有ディスク© 2024 NTT DATA INTELLILINK Corporation

運用管理製品
技術者
クラスタミドル
技術者
対象クラウド技術社

多くの製ス
キ品ル
数が必要××

IP付け替え処理×

VPC Peer間のFIP

運用管理製品12

3
運用管理における課題とFAQ ハイブリッドクラウド編© 2024 NTT DATA INTELLILINK Corporation

13

統合管理
ハイブリッドクラウドの運用の課題
ハイブリッドクラウドの流れ異なるレイヤのクラウドを組み合わせるハイブリッドクラウドですが、プライベートクラウドを基礎基盤として用途に応じてパブリッククラウドと連携する組み合わせが多いです。
・クラウドベンダロックイン排除
・重要データの持ち出しの困難性

ハイブリッドクラウド統合管理
Hinemosは単一画面でオンプレミス、仮想化、クラウドなどを組み合わせたヘテロな環境を俯瞰的に管理することができます。クラウドについては、動的に変更するインフラ運用を吸収し、オンプレミス環境のときと同一のイメージで運用を行えます。

・適材適所でのクラウド利用
・スモールスタート

利用用途に応じて選択

パブリッククラウド
ハイブリッドクラウド

ハイブリッドクラウドの運用要件
ハイブリッドクラウドの運用を行う際に、次の2つが重要な運用用件になります。当初、プライベートクラウドのみを運用を行い、順次パブリッククラウドを活用していくようなケースにおいても、本要件を満たす製品を選定しておくことが重要です。

• 俯瞰的な管理が出来ること

各クラウド個別の製品・サービスを導入しての運用管理は、エンジニアの習得や日々のオペレーションなど様々なカットで運用コストが増大します• マルチインフラでの動作サポート

対象環境で運用製品のマネージャやエージェントが動作することは最低限の要件です。
商用製品の場合は特に、可用性やライセンス費用も含めた確認が必要です。

Hinemosは多種多様なクラウドサービス上で動作します。運用管理を行うために、その環境にHinemosマネージャを構築するという制約はありません。VMware環境上のHinemosからAWSの運用管理も可能です。

• 動作確認済みクラウドサービス
AWS, Microsoft Azure, Google Cloud, OCI,IIJ GIO Managed Cloud Platform, Enterprise Cloud, ニフクラ, IBM Cloud• 動作確認済みハイパーバイザ
VMware, Hyper-V, Xen, KVM© 2024 NTT DATA INTELLILINK Corporation

14費用体系
CPU数・管理対象数変更によるライセンス変動

リソース・管理対象数に依存しない費用体系
Hinemosはコア数や管理対象数に依存する費用体系ではありません。そのため、マネージャやエージェントが動作するサーバのスペックや管理対象数に依存せず利用することが可能です。

リソース拡張・追加に影響
一般的な運用管理製品はCPUコア数、もしくは管理対象台数に依存して費用が変動します。そのため、クラウドのメリットである柔軟なリソースのスケールアップ・ダウン、スケールイン・アウトを実現しようとすると運用管理製品のライセンス費用という価格的な課題が生じます。
スケールアップ

一般的な運用管理製品

費用

Hinemos

一般的な運用管理製品は費用が変動する

Hinemosはコア数・管理対象数に影響しない費用体系

16core8core

スケールアウトスケールイン

4core

CPUコア数の変更

管理対象数の変更

運用管理製品の費用に変動が生じてしまう！

マシンスペック・配置設計に影響
プライベートクラウドにコアライセンスの運用管理製品を導入する場合、エージェントを導入する仮想マ
シンのCPU数はもちろんのこと、仮想マシンが動作するサーバのCPU数にも、ライセンスコストが影響するケースもあります。

• ハイスペックマシンの利用に影響

4コア/台

8コア/台

16コア/台

コア数/管理対象数

そのため、一旦導入した環境において、仮想CPU数の変更や動作するホストサーバの変更、必要に応じた仮想マシンの追加（スケールイン・アウト）について、費用について意識することなく実施することができます。これにより、柔軟にリソースを変更できるクラウドのメリットを享受することができます。

システムA
負荷増加

Hinemosの費用変動なし

システムA

コアライセンス製品では管理対象数が少なくてもCPUコア数の多いハイスペックマシンでは費用が高額になり、簡易に処理能力の高いマシンを利用できるというクラウドのメリットを享受できない。

• 仮想マシンの配置場所の設計に影響あるホストサーバのリソースが厳しくなった場合に、その上で動作する仮想マシンを別のホストサーバに移動しようとした際に、ライセンスコストの変動がないかを確認するといった、配置設計を意識する必要がでてくる。

クラウド・VMware等の仮想環境構成変更に対する運用製品コストの変動を意識する必要がない© 2024 NTT DATA INTELLILINK Corporation

15

FAQ

クラウドにおける運用管理基盤の検討順は？

監視はコモディティ化され、一番最後に選択したとしても選択肢は残ります。
そのため、監視は必須だといっても、「監視製品から」選定を、では全体最適となる構成は組めません。

監視機能の実現
最初に決めてしまうとジョブ機能の実現
高くて選択肢が少ない！

ログ機能の実現
高くて選択肢が少ない！

高価、クラウド対応が進んでいない製品（例：ジョブ管理製品）の検討・製品選定を、まず初めに行うことをお勧めします。
Hinemosを選択すると、その時点で全体最適（費用・構成）な運用管理基盤ができます。

ジョブ機能の実現
Hinemosにするとログ機能の実現…

監視機能の実現
Hinemosでできる！

Hinemosでできる！

© 2024 NTT DATA INTELLILINK Corporation

16

FAQ

監視におけるHinemos採用メリットは？
基盤専用の監視ツール/サービスと比べてもHinemos採用のメリットは多々あります。

観点

Hinemos基盤専用ツール/サービス

リソース情報の保存期間

ユーザ指定（ディスク容量次第）

保存期限ありのケースが多い
古いデータは間引きされるケースが多い

カレンダ連携高度なカレンダ定義可能

詳細が設定できないケースが多い

外部通知

高度な通知設定可能

外部サービスとの連携、作り込が発生し、流量制限ありのケースがある

ジョブ連携

可能

外部サービスとの連携、作り込みが必要
高度なジョブ定義は不可のケースがある

イベント集約基盤・システム、様々なカットでイベント集
約

ジョブ管理や業務管理を別の仕組みを用意すると、それらの集約が必要になる

マルチクラウドハイブリッドクラウド

基本操作変更なし

個別に仕組みを検討、再度作り込が必要の可能性がある© 2024 NTT DATA INTELLILINK Corporation

17

FAQ

Hinemosマネージャはどこに配置すればよい？
ハイブリッドクラウド運用の場合にHinemosマネージャをどこに配置すべきかは、SLA（クラウド間のNW障害）、NWトラフィックの観点で決定します。
SLA（クラウド間のNW障害）

ハイブリッドクラウド
NW障害から復旧までの間の監視やジョブ制御をどう見るか？

パブリッククラウド
NWトラフィック

ハイブリッドクラウド
多くのクラウドサービスはアウトバウンドに費用が掛かります
インバウンド無料

パブリッククラウド

アウトバウンド有料

上記理由より、次のような配置設計を採用されるケースが多いです。
・プライベートクラウド側に親（集約）Hinemosマネージャを配置
・拠点毎に子（テナント別）Hinemosマネージャを配置© 2024 NTT DATA INTELLILINK Corporation

18

FAQ

マルチテナント運用におけるHinemosマネージャの配置は？
クラウド環境を活用して、小規模から大規模の様々なテナントに対して、Hinemosマネー
ジャをどのように配置すべきかは、テナントの規模・SLAの観点でカテゴライズしたルールを決定することが多いです。（以下、カテゴライズ例）

梅コース

竹コース

松コース

Hinemosマネージャ
シングル構成Hinemosマネージャ
シングル構成Hinemosマネージャ
HA構成・その他【梅コース】
・Hinemosシングル構成
・1マネージャで複数テナント共用【竹コース】
・Hinemosシングル構成
・1マネージャ1テナント占有【松コース】
・Hinemos HA構成
・1マネージャ1テナント占有・規模により複数マネージャ占有【用途】
・小規模向け（台数）
・低SLA

【用途】
・中規模向け（台数）・NWセキュリティ要件（NW独立）
・中SLA

【用途】
・大規模向け（台数）・NWセキュリティ要件（NW独立）
・ジョブ/監視の高可用性要件© 2024 NTT DATA INTELLILINK Corporation

19

4appendix© 2024 NTT DATA INTELLILINK Corporation20

Hinemosではじめる

実践ジョブ管理・自動化入門
技術評論社
2023.3.9 発売開始
最新バージョン ver.7.0に対応

Amazonから購入可能© 2024 NTT DATA INTELLILINK Corporation21

お問い合わせはこちら
お待ちしているもに！

Hinemosに関するお問合せ
お気軽にお問合せください。
Hinemosポータルサイト
URL：https://www.hinemos.info/contact

ご相談
フォ
ーム

© 2024 NTT DATA INTELLILINK Corporation22

© 2024 NTT DATA INTELLILINK Corporation