Hinemos

  • RSS
  • Twitter
  • NTTデータ
  • Hinemosとは
  • 製品・サービス
  • 導入・保守のご相談
  • 導入事例
  • 技術情報

Hinemosのキューを使ったシステム間連携(Amazon SQS編)

作成日 2015/1/29
更新日 2015/1/29

 

概要

この技術情報では、クラウドを跨ったHinemosマネージャのジョブフロー連携をAmazon Simple Queue Service(Amazon SQS)を利用して行う方法を説明します。これは、HinemosからAmazon SQSへのメッセージ送受信することで実現します。このAmazon SQSへのメッセージ送受信するスクリプト(キューサービス連携スクリプト)は、本技術情報からダウンロードできます。

 

この技術情報は、AWSを含むマルチクラウド、ハイブリッドクラウド環境の利用を検討しているユーザを対象としています。

 

<参考情報>
Hinemosの[実践]入門の本が出ました。Hinemosをもっと詳しく知りたい方は、以下の書籍がお勧めです。

Hinemos統合管理[実践]入門

 

課題

Hinemosでは、単一クライアント単一マネージャにて(密な)マルチクラウドを統合的に管理することが出来ます。しかし、要件として複数のクラウドサービスを利用する際に、各々の関係を疎にする必要があるケースがあります(疎なマルチクラウド)。そして、それらが連携してマルチクラウド全体で自動化を実現するといったことが求められます。例えば、次の様なマルチクラウド運用が該当します。

 

ユースケース① 企業や部門を跨るシステム間連携

ユースケース② 災対サイト運用
 

このような環境やシステム間を跨る連携を、独自の作りこみや新規ソフトウェアの導入することなく、実現できることが求められます。そして、Hinemosではこれを簡易に実現することができます。

 

本技術情報では、Amazon SQSを使ったメッセージの連携を説明します。ほかにも、HinemosではHulftを使用したデータ連携も簡易に行うことができます。

 

メリット

この技術情報を用いることでユーザが得られるメリットについて説明します。

 

・簡単なセットアップ
 AWS CLIを利用するとAmazon SQSへのメッセージの送受信は可能ですが、必要な機能に絞ってリトライ処理なども合わせて作りこみされたスクリプトが入手できます。
 そして、AWS CLIのセットアップから、Amazon SQSへのメッセージの送受信を行えるまでの手順も整備されているため、簡易に環境のセットアップが行えます。

 

・Hinemosで利用する際のHowTo情報
 Hinemosからキューサービス連携をする際の設計の考え方が分かります。 

 

前提条件

この技術情報を用いる上で前提条件を説明します。

 

・AWSアカウント
 読者のAWSアカウントを利用します。
 このアカウントでは、1つのAmazon SQSの作成が必要です。
 キューサービス連携スクリプトは、AWS CLIにてAmazon SQSにアクセスするため、アクセスキー、シークレットキーが必要になります。 

 

対象環境

この技術情報を適用する環境について説明します。本技術情報では、CentOS 6.5、Hinemos v4.1の環境を想定します。

 

[キューサービス連携スクリプトの動作環境]
・インターネットに接続可能なLinuxサーバ
 AWSのエンドポイントに接続可能なインターネット接続環境が必要です。
 オンプレミス環境、仮想化環境、パブリッククラウド環境上の何れも問いません。

 

・AWS CLIのインストール
 AWS CLIを使用します。
 セットアップ方法はキューサービス連携スクリプトのREADMEを参照してください。

 

・Hinemosのインストール不要
 キューサービス連携スクリプトを動作させるだけの場合には、Hinemosのインストールは不要です。

 本技術情報では、Hinemosと連携させるため、後述のとおり、Hinemosのインストールが必要です。

 

[本技術情報の動作環境]
本来の目的は疎なマルチクラウドで動作する複数のHinemosのジョブフローの連携になりますが、今回は簡易な動作確認を行うため、1つのHinemosマネージャで動作を確認します。1台のCentOS 6.5環境にHinemosマネージャとHinemosエージェントをインストールします。Hinemosに登録する際のノード名をHinemosQueueManagerとします。

 

 

そして、JOBNET_AとJOBNET_Bの2つのジョブネットを作成し、JOBNET_A ⇒ Amazon SQS ⇒ JOBNET_Bといったジョブフローを実現します。

 

 

実現方法/解決策

技術情報を実現する方法について説明します。

 

1.キューサービス連携スクリプトのセットアップ
2.キューサービス連携するジョブネットの設定

 

------------------------
1.キューサービス連携スクリプトのセットアップ

[Amazon SQSとは]
Amazon SQSは、AWSのメッセージキューサービスです。

今回は、読者のAWSアカウントに次の名前のキューが事前に作成されていることを想定します。
動作確認するという観点では、キューを作成する際にキュー名以外の細かな設定は必要ありません。

 

- リージョン : アジアパシフィック(東京)リージョン(ap-northeast-1)
- Queue Name : HinemosSQS

 

[キューサービス連携スクリプトとは]
キューサービス連携スクリプトは、Amazon SQSへメッセージの送信、取得、削除の3つの処理を行うスクリプトです。
次の機能を持ちます。

 

- Amazon SQSへメッセージ送信

 Amazon SQSへメッセージを送信します。

 

- Amazon SQSへメッセージ取得

 Amazon SQSからメッセージを取得します。取得できるまでリトライを行います。取得したメッセージはキューから削除され、引数で渡したセッションIDのファイルをローカルの/tmp配下に作成します。

 

- Amazon SQSからメッセージ削除

 ローカル(/tmp配下)に作成したセッションIDのファイルを削除します。
 必要な処理が完了した後にこのセッションIDの削除を動作させることで、処理が正常終了したことを判定します。

 

キューサービス連携スクリプトは以下のリンクからダウンロードしてください。

キューサービス連携スクリプト for AWS のダウンロード

セットアップ方法は、ダウンロードファイルの中に含まれるREADME.txtを参照してください。 

 

------------------------
2.キューサービス連携するジョブネットの設定

[ジョブ定義]
ジョブパースペクティブのジョブ[一覧]ビューより作成します。

 

JOBNET_A
  JOB_A_1 業務処理A
    コマンド sleep 180
  JOB_A_2 メッセージ送信
    コマンド /opt/script/sqsmessage_send.sh -p default -n HinemosSQS

 

<JOB_A_1>


 

 

<JOB_A_2>

 

JOBNET_B
  JOB_B_1 メッセージ取得
    コマンド /opt/script/sqsmessage_receive.sh -p default -n HinemosSQS -s #[SESSION_ID] 
  JOB_B_2 業務処理B
    コマンド sleep 180
  JOB_B_3メッセージ処理完了
    コマンド /opt/script/sqsmessage_file_delete.sh -s #[SESSION_ID]

 

<JOB_B_1>


 

 

<JOB_B_2>


 

 

<JOB_B_3>

 

[ジョブスケジュール定義]
ジョブパースペクティブのジョブ[実行契機ビューより作成します。

SCHE_A
  JOBNET_Aの起動スケジュール
  毎時0分開始の10分間隔で実行

SCHE_B
  JOBNET_Bの起動スケジュール
  毎時5分開始の10分間隔で実行

 

<SCHE_A>


 

<SCHE_B>

 

例えば、ジョブスケジュールSCHE_AとSCHE_Bを有効にすると、18時では次のようなフローで動作します。

<時系列の動き>

・18時00分 JOBNET_A起動
 JOB_A_1 業務処理A ⇒ 3分間「実行中」となる

・18時03分 JOB_A_2 ⇒ JOBNET_Aが終了したことをSQSに送信

・18時05分 JOBNET_B起動
 JOB_B_1 ⇒ JOBNET_Aが終了したことをSQSから受信
 JOB_B_2 業務処理A ⇒ 3分間「実行中」となる

・18時08分 JOB_B_3 ⇒ JOBNET_Bの処理が正常に終了するとセッションIDのファイルを削除する

 

利用例/ユースケース

技術情報を利用するシーンの例、ユースケースを説明します。

 

ユースケース① 企業や部門を跨るシステム間連携
クラウドの料金体系とロケーションを活用し、ECサイトをMicrosoft AzureとBizホスティングCloudnに構築し、販売情報分析システムをAWSといったマルチクラウドの利用が考えれます。

このとき、ECサイトの販売情報をAWS上に構築したシステムで分析するための連携が発生します。

 

 

ユースケース② 災対サイト運用
本番環境をVMwareにて構築したプライベートクラウド環境とし、災対環境をAWSのパブリッククラウド環境を構築するといったことが考えられます。

この本番環境、災対環境は、各々独立し稼働する必要があり、しかし本番環境の環境変更を災対環境に自動的に同期するといった連携が発生します。

 

 

AWS環境に災対サイトを構築することは、AWSの外から中へのNW転送が無料であることやAWSのEC2インスタンス停止中の料金が非常に安い課金体系と、海外といったロケーションを活かしたハイブリッドクラウドならではのシステム構成です。 

 

免責事項

本ソフトウェアの使用・本ドキュメントに従った操作により生じたいかなる損害に対しても、 弊社は一切の責任を負いません。

 

注意事項

本ドキュメントの内容を実施すると、AWSにおいて料金が発生する場合があります。AWSの料金体系等を理解した上で操作を実施してください。
 
本ドキュメントにおいて、2014年12月現在の AWSのサービスに従い記載しておりますが、AWSのサービス変更に伴い、これらの操作が変更となる可能性があります。

 

関連情報

クラウド管理スタートアップ for AWS(環境構築編)

クラウド管理スタートアップ for AWS(自動化編)

クラウド管理スタートアップ for AWS(監視編)

Hinemosクラウド管理オプション

Hinemos各種オプション製品リーフレット

クラウド特集

Hinemosクラウド管理オプションのダウンロード(SourceForge.JP)

 

お問い合わせ

お問い合わせフォームへ

 

  • 紹介セミナー
  • お申し込みはこちら
  • ハンズオン研修
  • お申し込みはこちら
  • お見積依頼
  • 研修サービス
  • ダウンロード
  • クラウド特集
  • ジョブ特集
  • お問い合わせ
  • FAQ