202106版

HinemosでAWS運用を実現するメリット
NTTデータ先端技術株式会社
2021年6月© 2021 NTT DATA INTELLILINK Corporation

Hinemosとは© 2021 NTT DATA INTELLILINK Corporation2

対応プラットフォーム
RHEL

CentOS

OracleLinuxAmazon
LinuxSUSE

ubuntuWindowsServerWindows
7, 8, 10

OracleSolaris

HP-UX

AIX

Linux onPower/zOS

サーバ仮想化
コンテナ

VMwareHyper-V

XEN

KVM

Docker※開発中

AWS

OracleCloud

MCP

IIJ GIO

Azure

Enterprise
Cloud

NIFCLOUD

IBM
Cloud

GCP

クラウド

ソリューション
連携

OracleExadata© 2021 NTT DATA INTELLILINK Corporation

ServiceNow

SAP

3JiraService
DeskRedmine

INDEX

1. AWS編
2. パブリッククラウド編

3. ハイブリッドクラウド編© 2021 NTT DATA INTELLILINK Corporation

4

AWS編
運用管理における課題とFAQ© 2021 NTT DATA INTELLILINK Corporation

5

FAQ CloudWatchがあるのにHinemosは必要？
性能値のカバー範囲

営業日・営業時間の判断

データの保存期間

CloudWatchは、・PaaSのため必須
・OS上の性能値は苦手（ディスク使用率が取れない）

CloudWatchは、・性能値の取得可否はリソースが起動してるか否か

CloudWatchは、
・1 分毎のデータ→15 日間・5 分毎のデータ→63 日間
・1 時間毎のデータ→455 日間

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

・営業日・営業時間に性能値が取れていないと異常と判断可能・ディスク容量次第で設定可能

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

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

CloudWatchも運用管理製品も必要

Hinemosでは？
CloudWatchとシームレスな連携© 2021 NTT DATA INTELLILINK Corporation

ジョブが具備する高度なカレンダ
6

任意の期間でデータ保存

監視

AWS環境の監視はインフラ・専用リソース・操作ログの監視が必要
AWS環境の監視の課題

HinemosによるAWS環境の統合管理
Hinemosを導入することで、ユーザが作りこみをする必要なく、AWSの監視に必要な機能の連携を実現します。

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

CloudWatchの課題
・保存期間が最大でも15ヶ月
・業務カレンダとして連携した監視/通知抑制
・業務層の監視(Webシナリオ監視等)
・OS上のリソース値は取得不可(ディスク使用率等)

Health Dashboard連携

Amazon CloudWatchAWS CloudTrailAWS Service HealthDashboard連携

AWS環境はクラウドサービスとして提供されたインフラですが、このインフラ・サービスが正常に動作していることを監視する必要があります。
これはAWS Service Health DashboardからRSS経由で独自で監視する必要があります。

CloudTrail操作ログ監視
AWS環境のインターネット環境に公開されたパブリッククラウドです。そのため、AWS環境変更については、プライベートクラウドよりセンシティブに管理・監視が必要です。

API 操作ログ• 不正なログイン• 許可の無いEC2インスタンスの作成• 危険なセキュリティグループの変更

AWS CloudTrail© 2021 NTT DATA INTELLILINK Corporation

ターゲットシステム7

運用自動化

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

AWS環境の運用自動化の課題

Hinemosによる運用自動化
HinemosにAWSへの接続情報(アクセスキー・シークレットキー)を登録すると、AWS上のEC2インスタンス情報を取得し、リージョン、アベイラビリティゾーン、VPC、サブネットの単位で自動グルーピングします。運用開始後も自動追尾して、環境変更時に伴う運用操作は必要ありません。
自動構成管理環境変更への追随
柔軟なリソースコントロールができるAWS環境においては、その環境変更による運用コストの低減が課題になります・EC2インスタンスの検出(初期構築/オートスケーリング)
・リージョン、アベイラビリティゾーンへのマッピング(ロケーション)
・VPC、サブネットへのマッピング(ネットワーク構成)
運用対象の構成把握に運用コストが掛かる

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

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

①自動検出

②識別

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

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

© 2021 NTT DATA INTELLILINK Corporation

タグを使った自動識別EC2インスタンス③監視・ジョブ
開始

Webサーバスコープ割当ルール＋

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

検出識別

APサーバ

タグ情報

DBサーバ

8

リソース制御

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

AWSのリソース制御の課題

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

AWS Auto Scalingの課題
AWS Auto Scaling は非常に有用なソリューションですが、スケールイン・スケールアウトのトリガーの条件設定が難しく、予期せぬタイミングでトリガーが発動するかもしれません。また、条件によっては、試験ができないケースがあります。そのため、単純にEC2インスタンスを消さずに、必要に応じて起動・停止だけするケースも多くあります。
追加

Auto Scaling group

夜間
止めたい

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

削除

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

運用者

リソース制御と業務連携
・スケジュール起動・カレンダ制御

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

AWS Cloud

単純な起動・停止は可能

どうやって連携する？

運用者© 2021 NTT DATA INTELLILINK Corporation

システム
閉塞

マシン
停止

マシン
起動システム
開放

AP停止

LB閉塞

通常の運用管理製品

EC2停止

業務処理のフロー管理は可能

9

バックアップ参考情報

HinemosによるAWS使用料金の削減

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

Hinemosの計画停止コントロールによる料金削減検証

・土日を停止できれば70％

月-金
→ 5/7

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

月-金&8:00-24:00→ (5/7)x(16/24)© 2021 NTT DATA INTELLILINK Corporation

10

OSサポートレベル
OSサポートレベルの課題

Hinemosの動作対応環境
Hinemosマネージャ、Hinemosエージェント共に、 AWS上でOLTが提供されるOSのAmazon Linux 2及び、OpenJDK互換のAmazon Corettoに対応しています。
これにより、AWS上でセキュアで安定した環境での運用管理が実現できます。

OSのセキュリティ対応
Red Hat Enterprise Linux等の商用OSについては、OSのアップデートやセキュリティパッチの入手が、オンプレミス環境より、クラウドの方がワンテンポ遅くなります。

オンプレクラウド

ユーザ

OS
ベンダ検証

Amazon Linux 2対応

入手・Red Hat Enterprise Linux 7ベース(2019.4)
・長期サポート・AWS上の他、VMwareやDockerイメージ公開
・EC2に最適化
・セキュリティアップデート

ユーザ

クラウド
ベンダ検証

OS
ベンダ検証

入手

Javaサポート
現在でも多くのアプリケーション・ミドルウェアにJavaが必要です。独自のOSが登場すると、そのOS上でどうするJava Runtimeをどうするか、が課題になります。
Red Hat Enterprise Linux上のOpenJDKはRed Hatがディストリビュータとして公開・サポートするJavaです。

OS

Java

Javaディスト
リビュータ
サポート期限RHEL7

OpenJDK8

Red Hat2023年6月

独自OS？

？

？

© 2021 NTT DATA INTELLILINK Corporation

11

Amazon Coretto対応
・2019.4正式リリース
・Amazonによるサポート
・無料
・マルチプラットフォームサポート

監視

クラウドのログは収集と監視の統合管理が必要
AWSのログ管理の課題

Hinemosによるログ統合管理

ログ収集の統合管理
パブリッククラウドの場合、WindowsやLinuxの仮想マシンだけなくロードバランサといったPaaSがあります。PaaSのログを収集監視しようとするとログを集めてくることだけを前提としたログ監視製品では対応できず、そのクラウドのログサービスが必要になります。

OS・MWのログ

PaaSのログOS・MWのログ

既存のログ管理製品

PaaSのログ

Hinemosではクラウドのログサービスにあるログを対象に監視が行えます。これにより、他にHinemosで監視しているログファイル・メッセージに対するフィルタ条件や、業務カレンダによる制御、通知抑制やジョブフロー連携も簡易に可能です。
また、Hinemosをログ収集エンジンとして、ログサービスから取得して蓄積管理が、可能になります。

フィルタ条件を集約

業務カレンダの適用

メッセージバースト対応
通知・アクションの集約

対象クラウドのログサービス

ログ監視の統合管理

シームレスな監視

しかし、クラウドのログサービスにログを収集・集約したとしても、ログ監視は複雑なフィルタ条件や、業務カレンダの連携、異常検知後の通知・自動化の連携が重要ですが、一般的な運用管理製品がもつレベルの機能まではクラウド側に用意されていません。

Amazon CloudWatch Logs

ログ監視の要素
フィルタ条件の集約

業務カレンダの連携

高度な通知や自動化の連携・決まった記述ルール（正規表現）
・順序性/判定有無

・メンテナンス時間の監視無効化

・メッセージバーストを防ぐ
抑止機能
・通知・自動化先の集約© 2021 NTT DATA INTELLILINK Corporation

必要に応じて収集・蓄積

次期バージョンで機能強化
12▲

✔

✔

自動化

運用自動化には双方向の連携が必要

クラウド環境との双方向連携の課題

Hinemosによる双方向連携

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

クラウド側の自動化

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

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

運用管理ソフト側の自動化
運用管理ソフト・PaaSのアプリケーション
・サーバレスのアプリケーション

ジョブ2

ジョブ1

アプリ2
ジョブ1

マルチクラウドの連携

アプリ1

アプリ2

どうやって連携しよう

運用者© 2021 NTT DATA INTELLILINK Corporation

ジョブ4

アプリ1
アプリ3

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

クラウドA

クラウドB

クラウドA

業務ジョブフロー連携

AWS
Lambda

クラウドB

アプリ3

アプリ4

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

ジョブ3

次期バージョンで機能強化
13

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

14

運用管理の可用性

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

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

可用性の要件の違い

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

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

Hinemos
マネージャ

仮想化環境

オンプレミス環境

・仮想OSの障害・ホストマシンの障害
・データストアの障害

クラスタリングソフトや共有ディスクは不要

・仮想OSの障害
・データセンタ障害

環境非依存/FIP不要

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

オンプレミス、仮想化、クラウド環境で同じ構成で可用性構成が組めます。構成がシンプルのため、設計・構築時のSE/CEコストの削減が可能です。FIPを使用せず可用性構成を組めます。

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

クラスタミドルの問題
FIP(FloatingIP)の問題

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

ロストなしの監視クラスタミドルを使用しない独自な構成により、syslogやsnmptrapもロストなしで監視ができます。

運用管理製品の問題※参考情報（クラウドにおけるクラスタ構成の様々な制約）に詳細を記載© 2021 NTT DATA INTELLILINK Corporation

Hinemos
マネージャ

レプリケーション

クラウド環境・サーバ障害

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

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

ジョブ管理の冗長化

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

参考情報

クラウドにおけるクラスタ構成の様々な制約

クラスタミドルの問題

共有ディスクの問題

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

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

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

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

運用管理製品の対応

クラスタミドルの対応〇？

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

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

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

〇？

〇or×

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

DBサービス(RDS等)〇？

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

FIP(Floating IP)の問題

運用管理製品の問題

AWSの問題Azureの問題

組み合わせサポート

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

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

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

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

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

時間が掛かる

クラスタミドル

Direct Connect間のFIP

×

ロードバランサ
方式推奨© 2021 NTT DATA INTELLILINK Corporation

クラウド依存SI構築が発生16

セッ製ト品で数判
断共有ディスク

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

対象クラウド技術社

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

×

運用管理製品×

VPC Peer間のFIP

IP付け替え処理ハイブリッドクラウド編
運用管理における課題とFAQ© 2021 NTT DATA INTELLILINK Corporation

17

統合管理
ハイブリッドクラウドの運用の課題

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

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

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

利用用途に応じて選択

ハイブリッドクラウド

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

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

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

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

対象環境で運用製品のマネージャやエージェントが動作することは最低限の要件です。商用製品の場合は特に、可用性やライセンス費用も含めた確認が必要です。
© 2021 NTT DATA INTELLILINK Corporation• 動作確認済みハイパーバイザ
VMware, Hyper-V, Xen, KVM

18

FAQ クラウドにおける運用管理基盤の検討順は？
監視はコモディティ化され、一番最後に選択したとしても選択肢は残ります。
そのため、監視は必須だといっても、「監視製品から」選定を、では全体最適となる構成は組めません。

監視機能の実現

ジョブ機能の実現

最初に決めてしまうと高くて選択肢が少ない！

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

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

ジョブ機能の実現
Hinemosにすると© 2021 NTT DATA INTELLILINK Corporation

ログ機能の実現…

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

Hinemosでできる！

19

費用体系
CPU数変更によるライセンス変動

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

リソース拡張に影響一般的なジョブ管理製品は、CPUコア数に依存して費用が変動します。そのため、サーバ台数が少なくても費用が高額になるケースがあります。CPU処理能力が必要なサーバが簡易に利用できるクラウドのメリットに、価格的な課題が出てきます。

ハイパフォーマンス
サーバ
Web
サーバ

AP
サーバ

高負荷
処理

運用
サーバ

CPUコア数 数十以上
システムオールインワン構成

コアライセンスの製品

費用

Hinemos

コアライセンスの製品は費用が変動する

Hinemosはコア数に影響しない費用体系

ハイパフォーマンスなサーバを使用するとたった1台でも非常に高額な費用となる

4コア

16コア

コア数

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

配置設計に影響
プライベートクラウドにジョブ管理製品を導入する場合、エージェントを導入する仮想マシンのCPU数だけではなく、仮想マシンが動作するサーバのCPU数にも、ライセンスコストが影響するケースもあります。

仮想マシン
リソース不足• 仮想マシンのCPU追加に影響リソースが不足した際にCPU数を追加するといった、クラウドのメリットが、運用管理製品のライセンス体系の問題で、享受できない。

CPUCPU

Hinemosの費用変動なし

仮想マシン
CPU

CPU

CPU

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

8コア

構成変更に対する運用製品コストの変動を意識する必要がない

20

CPU

まとめ

© 2021 NTT DATA INTELLILINK Corporation

21

まとめ
• AWS、パブリッククラウド全般、ハイブリッドクラウドの3つのカットで、運用管理の課題とFAQを紹介• クラウド専用機能、クラウドに適したアーキテクチャと費用体系で、クラウド利用メリットをHinemosが促進• Hinemosがプラットフォーム差分を吸収して、ユーザに本質的な運用設計に注力を可能に

クラウド運用と言えば、Hinemos！
© 2021 NTT DATA INTELLILINK Corporation22

お問い合わせはこちら• 本サービスのお申し込みは下記よりご連絡ください。

ご相談
フォ
ーム

© 2021 NTT DATA INTELLILINK Corporation

23

お待ちしているもに！

© 2021 NTT DATA INTELLILINK Corporation