AWS Partner SA ブログ

[OpsJAWS] RDSイベントの監視

RDSメンテナンスイベント監視の目的

RDSもDBインスタンスのOSメンテナンスや、DBエンジンのメンテナンスなどの計画メンテナンスが実施されることがある。RDSメンテナンスイベントの検知後に、任意のタイミングでメンテナンス実施、事前に指定したメンテナンス期間で実施、もしくは延期などの対応が取れるため、RDSメンテナンスイベントの発生を監視することも必要となる。

RDSメンテナンスイベントの監視

RDSのメンテナンスイベントは、AWSアカウントに設定されたメールアドレス宛にメール通知される他、Management Consoleからの確認や、AWS CLI/APIによる確認が可能である。メールによる通知だけに頼ると見逃してしまうリスクがあるため、定期的にCLI/APIを実行してメンテナンスイベント有無を監視することが望ましい。メンテナンスイベント監視に使用するCLI/APIはそれぞれ下記となる。

• API：DescribePendingMaintenanceActions
• CLI ：describe-pending-maintenance-actions

出力として、イベントの種類、イベントの説明、イベント予定時間帯（メンテナンス期間に設定した時間帯）、イベントが強制的に実施される時間帯などの情報が得られる。例えば、CLIで下記のように実行すると、イベントが計画されているRDSの情報が出力される。

# aws rds describe-pending-maintenance-actions 

イベントの種類についての詳細は下記を参照。

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradingDBInstances.html#USER_UpgradingDBInstances.OSUpgrades 

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradingDBInstances.html#USER_UpgradeDBInstances.Upgrading

RDSイベント検知後の対応

RDSメンテナンスイベントを検知した場合の対応方法としては、下記の3通りが考えられる。

1．任意のタイミングでメンテナンスを実施する。

システム的に影響の少ないタイミングで先行してメンテナンスを実施する。RDSをMuti-AZ構成にしている場合スタンバイへのメンテナンス実行→スタンバイがプライマリに昇格→旧プライマリへのメンテナンス実行と言った順番でメンテナンスが実行されるため、メンテナンス時のシステム影響を小さくすることが可能となる。

2．事前に定義したメンテナンス期間内で実施

RDSインスタンスに設定されたメンテナンス期間内で実施されるようにスケジュール設定することが可能。そうすることでサービスへの影響を極力抑えた時間でのメンテナンスが可能となる。

3．メンテナンス項目の適用を延期

「Available」と表示されたメンテナンスは無期限に延期が可能なため、システムの安定稼働を優先する場合は延期するのも有効な選択肢の一つとなる。ただし、「Required」と表示されたメンテナンスについては無期限延期が不可能であるため、上記の1か2どちらかの対応が必要となる。

RDSイベントの監視

RDSインスタンスで発生した何らかの変更や障害、メンテナンス発生後の情報、Failover発生事象などはRDSイベントとして扱われる。RDSはイベントソースとカテゴリによって分類され、イベントソースはイベントの発生元を指し、カテゴリはイベントの区分を指す。

 

イベント内容の詳細についてはこちらを参照。

RDSイベントの監視方法

RDSイベント情報はManagement Console、AWS CLI/API、SNSで取得することが可能である。イベント情報は障害発生時の切り分け情報として必要になることが多いため、適切に蓄積しておくことが望ましい。SNS経由でメール通知が行えるため、これを利用してイベント情報を蓄積しておく。設定の際に、通知対象のイベントを絞り込むことが可能であるため、システムごとの要件に応じて通知対象のイベントを決めておくことが望ましい。詳細な設定方法はこちらを参照。

また、RDSサービスの正常性を表すカテゴリは下記となるため、正常性監視目的でイベントの監視を行う場合は、下記を通知対象とすることが望ましい。

一方、RDSサービスの変更情報を表すイベントは下記となるため、変更管理目的でイベントの監視を行う場合は、下記を通知対象とすることが望ましい。

 

その他運用カテゴリはこちらを参照。

[OpsJAWS] 死活監視 (General)

死活監視の目的

システム全体として正常にサービスを提供できていることに加え、障害時に原因を早期に切り分けるために、システムを構成する個々のコンポーネント、サービスそれぞれが正常に稼働していることを監視する必要がある。AWSの各種機能を利用して構築されたシステムにおいて、どのように死活監視を行うべきかを明らかにする。

WEBシステム全体の死活監視

WEBシステムにおいては、WEBリクエスト監視やWEBシナリオ監視を設定し、ユーザー視点でシステムが正常に稼働していることを監視することが必要となる。この際、監視経路が実際にユーザーがシステムを利用する経路と同じになるように設定することが望ましい。監視には、Amazon CloudWatchをベース考えに必要に応じ、監視ツールを導入する、もしくはMSPなどの監視サービスを利用する。WEBシステムが同構成の複数のWEBサーバからなる場合、Route53によるヘルスチェック機能も有効な手段となる。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
WEBリクエスト監視	監視ツール／ 監視サービスのWEBリクエスト監視機能	サービスサイトURLへのhttp/httpsリクエスト応答	高	WEBシステムのインフラレイヤ正常性監視
WEBシナリオ 監視		シナリオに沿ってログインやサービスサイトのページ遷移、ダミーデータ登録を伴うWEBサービス監視	高	WEBシステムのアプリケーションレイヤの正常性監視
Route53ヘルスチェック	CloudWatch	HealthCheckStatus HealthCheckPercentageHealthy	中	WEBシステムのインフラレイヤ正常性監視

[対処方法]

後述の、WEBシステムを構成する各要素、AWSサービスの正常性監視結果を元に障害発生箇所を切り分け、適切な復旧処置を実施する（下記参照）。

AWSサービスの死活監視

利用中のAWSサービスの正常性は、AWS Service Health Dashboardで確認できる。AWS Service Health Dashboardでは各リージョン毎のAWSサービスの正常性、性能低下、障害情報、障害復旧情報が確認できる。更新情報はRSSで配信されるため、監視するためには、RSSフィードを取得する機能を監視システムに実装する必要がある。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
AWSサービス正常性	Service Health Dashboardからの情報取得	RSSフィードを購読し、AWS ServiceHealthDashboardの更新状況を監視する	高	システムで利用中のAWSサービス正常性監視

個々のAWSサービスの死活監視

• Amazon Route 53の死活監視

Amazon Route 53はSLAで100%の使用可能時間割合を目標としている高可用性で設計されたマネージドサービスで、WEBリクエスト監視を通じRoute53の死活監視も行えるためRoute53単体での死活監視は不要である。

• Amazon CloudFrontの死活監視

Amazon CloudFront自身の死活監視はWEBリクエスト監視またはRoute53のヘルスチェックで行える。Route53をDNSサービスとして使用している場合は、Route53のフェールオーバー機能と連携して可用性を高められるので、HealthCheckを活用することが望ましい。

またCloudWatch経由でリクエスト数やHTTPレスポンスコードの発生率のメトリックスを取得し、リリクエスト数の推移、稼働状況を監視することで、想定の範囲内の動作か異常動作かを確認する。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
Route53ヘルスチェック	CloudWatch	HealthCheckStatus HealthCheckPercentageHealthy	高	WEBシステムのンフラレイヤ正常性監視
CloudFrontリクエストエラー率	CloudWatch	TotalErrorRate 4xxErrorRate 5xxErrorRate	中	WEBサイト／WEBアプリケーションの正常性監視

[対処方法]

Route 53のHealthCheck機能と連携し異常となった場合にCloudFrontにトラフィックを流さないように構成しておく。Route 53ではHealthCheckで異常になった場合に対象のIPアドレスを返さないようにする機能があるためRoute 53にPrimary（CloudFrontのFQDN）、Secondary（オリジンサーバのIP）を登録することで異常時には自動でSecondaryの方にトラフィックが流れ、可用性を高めることが可能。

CloudWatchで取得したCloudFrontのメトリックは障害原因調査のために利用する。

• Elastic Load Balancing (ELB) の監視

ELBの死活監視ではELB自身の状態と、ELBと配下のEC2インスタンスとの接続の正常性についてもCloudWatch経由で取得して監視する。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
ELBリスナー生成エラー数	CloudWatch	HTTPCode_ELB_4XX HTTPCode_ELB_5XX	中	不正な形式のリクエスト数やリクエスト数に対するELB容量が十分であるかを監視
ELB-EC2接続エラー数	CloudWatch	BackendConnection Errors HealthyHostCount UnHealthyHostCount HTTPCode_Backend_2XX HTTPCode_Backend_3XX HTTPCode_Backend_4XX HTTPCode_Backend_5XX	中	ELB-EC2間接続の正常性監視

[対処方法]

バックグラウンドEC2インスタンス側の正常性確認と合わせて原因を調査を実施する。

• Auto Scalingの監視

死活監視という観点でAutoScalingを監視する場合は、予期せぬScale Inが引き起こされないように、AutoScalingPolicyに設定された最低台数値とInserviceとなっているEC2インスタンス台数を監視する。主に作業時の設定ミスや自動運用での設定反映失敗などの検知が目的となる。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
Auto Scaling Groupの最低EC2インスタンス数	CloudWatch	GroupDesiredCapacity	中	予期せぬScale Inによるサービス停止の防止
Auto Scaling Groupの正常EC2インスタンス台数	CloudWatch	GroupInServiceInstances	中	必要な台数分のEC2インスタンスが確保出来ているかの確認

[対処方法]

GroupMinSize値の予期せぬ縮小を検知した場合は必要最低限の値まで引き上げる。異常となるEC2インスタンスの数が多い場合は障害未然防止のために原因調査を行う。

• Amazon EC2 の監視

サーバ死活監視としては、Ping応答やEC2ステータス監視、ELBからのヘルスチェックなどいくつか監視方法が存在する。EC2インスタンスがAutoScaling構成になっている場合、1台1台のEC2インスタンスの死活監視に注力するのではなく、Group全体でサービス提供できる状態になっているかどうかを監視し、監視項目を減らし運用負荷を下げることが望ましい。

AutoScaling構成の場合の死活監視は、AutoScalingやELBのヘルスチェック機能を活用して必要なEC2が稼働しているかを監視する。一方サーバ内のプロセス監視には、監視ツールや監視サービスを使用し、OSから情報を取得して監視する。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
AutoScaling Group所属のEC2死活監視	CloudWatch	GroupInServiceInstances GroupDesiredCapacity	中	必要な台数分のEC2インスタンスが確保出来ているかの確認
ELB配下のEC2死活監視	CloudWatch	HealthyHostCount UnHealthyHostCount	中	必要な台数分のEC2インスタンスが確保出来ているかの確認
AutoScalingGroup/ELB未登録のEC2の正常性監視	CloudWatch	StatusCheckFailed StatusCheckFailed_Instance StatusCheckFailed_System	高	EC2インスタンスと(インスタンスの稼働する)仮想サーバーホストの正常性監視
サーバプロセス監視	監視ツール／ 監視サービス	OSコマンドを実行して監視対象プロセスの稼働状況を確認	高	サーバプロセスの正常稼働を確認

[対処方法]

AutoScalingGroupに登録されているEC2の場合、AutoScaling機能により自動で復旧されるため対処は不要となる。障害となったEC2インスタンスを調査したい場合はCLIなどでサスペンドをかけることで一時的にAutoScalingの動きを停止することが可能。

非AutoScalingGroupのEC2インスタンスでStatusCheckFailed_Systemとなった場合には該当EC2のStop & Startを実施することで物理ホストが移動し復旧するケースが多い。これを自動で行うAutoRecovery機能を活用し非AutoScalingGroupのEC2についても自動での復旧が可能。

サーバ内正常性監視で異常が検知された場合、監視ツールや監視サービスの自動アクション機能でプロセスの再起動や復旧スクリプト実行を行うことで自動で障害復旧が可能となる。ツールやサービスによってはランブックオートメーションの機能で、単発のコマンド実行だけでなく、複数のコマンドを実行することでより複雑な障害復旧手順を自動化することが可能なものもある。

• Amazon EBSの監視

死活監視の観点ではディスクアクセス（Write/Read）が行えていることを監視するべきだが、Write/Read異常が発生するとプロセスダウン、やOSやアプリケーションなどのログ監視異常として検知できるため特段の監視は行わない。

• S3の監視

S3とデータ転送を行うアプリケーション側の監視に兼ねる。またはCloudFrontのオリジンサーバとしてS3を活用している場合はWEBリクエスト監視を行う。

• Amazon RDSの監視

APIを実行しRDSインスタンスのステータスを監視する。加えてアプリケーションがDBにアクセスできることを監視するために、ダミーSQLを発行してDBへのアクセスを監視する。またRDSが障害時の切り分け情報として使用するために、APIを実行してRDSインスタンスに発生したイベント情報を収集して監視する。

[監視対象]

監視項目	監視方法	取得方法詳細	優先度	監視目的
DBインスタンスステータス	その他	AWS APIs DescribeDBInstances	高	DBインスタンスステータスの正常性監視
SQLリクエスト監視	監視ツール／ 監視サービス	ダミーSQLを発行してDBにアクセスできることを確認	高	アプリケーションからDBにアクセスできる状態であるかを確認する
RDSイベント	その他	AWS APIs DescribeEvents	中	RDSのイベント情報を収集し障害調査に利用する。

[対処方法]

Multi-AZ構成の場合マスタが障害になった場合自動でスレーブにフェイルオーバする。この際エンドポイントは変わらないためアプリケーション側での対処は必要なし。Single-AZ構成の場合、バックアップとして取得したスナップショットからリストアして復旧する。またはDBエンジンによってはリードレプリカをマスタに昇格させることも可能。この際エンドポイントは変更になるためアプリケーション側で接続先を修正する必要がある。

• 構造

• 注意点

上述の通り、Route 53のヘルスチェック機能とフェイルオーバー機能の連動や、ELBヘルスチェックとAutoScalingの連動、EC2インスタンスステータスチェックとAutoRecover機能の連動など死活監視と自動復旧機能を組み合わせることで高品質、低コストの運用を行うことが可能。監視設計する際は対応する復旧方法まで考慮する。

その他運用カテゴリはこちらを参照。

AWS Summit 「無料で体験！AWS TestDrive コーナー」のご案内

Partner SA の井上です。
いつもお世話になっております。

みなさん、AWS TestDriveをご存知でしょうか？

TestDriveはその名の通りAWSのパートナー様ソリューションを”試乗”していただくことが可能です。
通常の車の試乗と同様でもちろん無料！です。（ご提供頂いているパートナー様には感謝です）
SAP on AWS といったビジネスアプリケーションの体験はもちろんビッグデータ・HPC・運用自動化といった様々なソリューションが試乗可能です。

さて、そんな AWS TestDrive ですが、以下のURLから"すぐに"・"簡単に"ご利用いただくことが可能です。

http://aws.amazon.com/jp/testdrive/

ただでさえ簡単なのですが、いよいよ次週に迫りました AWS Summit Tokyoでは、AWSのブース内にTestDriveコーナーを設けさせて頂きます。

題して「無料で体験！AWS TestDriveコーナー」。

今回は NEC様、NetApp様、Trend Micro様、Sophos様にブースでもご協力頂き、ご提供各社自らソリューションのご説明とサポートをして頂きます。
（なお、各社様には特定の時間帯でご協力頂いております。各社様の担当時間は会場でご確認ください。）

この機会にAWSパートナー様の素晴らしいソリューションを是非無料でご体験ください！

AWS Summit Tokyo の会場でお会いできることを楽しみにしております。

--
エコシステムソリューション部
パートナーソリューションアーキテクト
井上 和英

[ESP for AWS] AZAREA-Cluster (株式会社 シーエーシー) のご紹介

みなさんこんにちは。Partner SA井上です。
本日は、株式会社シーエーシー様のAZREA-Clusterを紹介させて頂きます。

--------
会社名:   株式会社シーエーシー

製品 / ソリューション名:  AZAREA-Cluster

 

 

システム構成図:
◆AZAREA-Cluster

 

製品/ソリューション概要:

AZAREA-Cluster はGUIでバッチアプリケーションの開発・保守が簡単・スピーディに行えるソリューションです。
専門言語を使うことなくグラフィカルな環境でバッチアプリケーションの開発(図1)が可能です。
また、AZAREA-Clusterがプログラムを自動的に並列化・最適化いたしますので、開発者は難しい並列プログラミングの知識が不要となります。

図1　[AZAREA-Clusterのフロー編集画面]

 ◆導入効果
・大量データを高速処理するバッチアプリケーションを、簡単に短期で開発･保守が可能です。
・専門技術を習得せずともHadoopを有効活用することが可能です。

◆対象ユーザー
以下の課題を抱えている方が対象となります。

・データ量が多く、バッチ処理時間が長いが、処理時間を短縮したい。
・複雑なバッチアプリケーションを開発・保守したい。
・Hadoopを使いたいが専門の技術者がいない。

 

システム要件/利用するAWSサービス:
システム要件：
　Java : 7以降
　Eclipse : 4.2以降
　OS : 上記が動作するOS (Windows, Linux, Mac)

利用するAWSサービス：
　EMR, S3

費用:
下記お問い合わせ先にお問い合わせください。

 

その他情報:
AZAREA-Cluster
http://www.cac.co.jp/product/azarea-cluster/

お問い合わせ先:
株式会社シーエーシー
ICT営業本部
[email protected]
03-6667-8059

 

 

[ESP for AWS] Deep Security (トレンドマイクロ株式会社)のご紹介

Partner SA松本です。AWS上で多くの実績があるセキュリティソフト Deep Securityについて、トレンドマイクロ株式会社の岩瀬様にご投稿いただきました。 

会社名:  トレンドマイクロ株式会社

製品 / ソリューション名:
Trend Micro Deep Security™ / Trend Micro Deep Security™ as a Service
 

システム構成図:

製品/ソリューション概要:
Trend Micro Deep Securityは、AWS環境に非常に親和性が高く、多くの導入事例を持つ統合型セキュリティ対策製品です。

昨今のサーバセキュリティに必要な6つのセキュリティ要素を、1つの保護モジュールでご提供します。全てのセキュリティ設定は、Web管理コンソールから一元的に行うことが出来ます。

【Deep Securityで提供できる、６つのセキュリティ機能】

不正プログラム対策	サーバに侵入するウイルス/マルウェアを検出し、駆除します。
Webレピュテーション	サーバから不審なWebサイトへのアクセスをブロックします。マルウェアの侵入や、不審なサイトへの情報アップロードを防ぐことができます。
侵入検知・防御（ホスト型IDS/IPS）	脆弱性をついた攻撃から、サーバを保護します。OSやミドルウェア、アプリケーションの脆弱性に対応したルールをトレンドマイクロから配信します。
ファイアウォール	ホスト単位での通信制御を行い、攻撃を受ける機会を軽減します。
ファイルやレジストリなどの変更監視	ファイルやディレクトリ等の改ざんを早期に発見します。
セキュリティログ監視	短い期間に大量のログイン失敗履歴が出力されているなどの、重要なセキュリティイベントを早期に発見します。

【AWSにおけるセキュリティの考え方】
AWSでは共有責任モデル（shared Responsibility Model）を採用しています。
Deep Securityは、ユーザ責任領域のセキュリティ確保にお役立ていただけます。

  

ポイント①　6つのセキュリティ機能で、AWS上のサーバの多層防御を実現！
ポイント②　Auto Scalingで増加したインスタンスにも自動的にセキュリティ保護を提供！
ポイント③　年額版、月額版をご用意。お客様のサーバ台数、規模に合ったセキュリティ対策が可能！

【主な利用シーン】

• EC2インスタンスのOSやミドルウェアの脆弱性対策を実施したい方
• クロスサイトスクリプティングやSQLインジェクションなどのWebアプリケーションの脆弱性を突く攻撃から外部公開しているEC2インスタンスを保護したい方
• 機密情報を扱う基幹システムへの攻撃にいち早く気づくために、各インスタンスで特定ディレクトリの変更監視を実装したい方
• AWSとオンプレミス環境のハイブリッド環境で動作するシステムに、一元的なセキュリティ管理を提供したい方
• EC2インスタンスのウイルス対策をしたい方
• コンプライアンスやセキュリティポリシーのために、ファイアウォールのブロックログを長期間保存したい方 

【構築手順】
Trend Micro Deep Security

1. 設定情報や検出ログを格納するデータベースを構築（RDS Oracle or Microsoft SQLが利用可能）
2. お客様が準備したインスタンスに、Deep Security Manager(管理サーバ)をインストール
3. 保護対象インスタンスにDeep Security Agent(保護モジュール)をインストール
   a. インスタンス起動時に、User Dataにスクリプトを記載してインストール
   b. 既に稼働中のインスタンスに、Agentインストーラを利用してインストール 

Deep Security as a Service（DSaaS）

1. DSaaSユーザ登録（Webフォームへの入力）
2. 保護対象インスタンスにDeep Security Agent(保護モジュール)をインストール
   a. インスタンス起動時に、User Dataにスクリプトを記載してインストールする
   b. 既に稼働中のインスタンスに、Agentインストーラを利用してインストールする

【操作画面】
Web管理コンソールのウィジェットで、各インスタンスのセキュリティ状況を一元的に管理することができます。

 

システム要件/利用するAWSサービス:
保護対応OS:
Windows XP/Vista/7/8/8.1,Windows Server 2003 SP2/2008/2012
Red Hat /Cent OS/SUSE/ Ubuntu /Cloud Linux/ Amazon Linux 等

※対応OSの詳細は、下記のシステム要件ページをご確認ください。
http://www.trendmicro.co.jp/jp/business/products/tmds/#requirement　

AWSサービス:
EC2, VPC, RDS 

AWSでの導入実績:

• 株式会社ワークスアプリケーションズ
• 株式会社　集英社
• コイニー株式会社
• 株式会社　エイチ・アイ・エス
• アステラス製薬株式会社     等
  http://www.trendmicro.co.jp/jp/business/solutions/publiccould/index.html#aws　

費用:
Deep Securityのライセンス体系は、こちらからご確認ください。
http://www.trendmicro.co.jp/jp/business/products/tmds/#price
※Deep Security as a Serviceの価格は、販売パートナー様までご確認ください。 

その他情報:
製品ご紹介ページ：<http://www.trendmicro.co.jp/jp/business/products/tmds/>
AWS Test Drive：<https://testdrive.trendmicro.com/jp/index.html>
AWS Marketplace：<https://aws.amazon.com/marketplace/pp/B00OCI4H82/ref=srh_res_product_title?ie=UTF8&sr=0-3&qid=1429174299088>
 

お問い合わせ先:
<法人お問合せ窓口>
TEL：03-5334-3601　/　FAX：03-5334-3639
<法人のお客さま向けお問い合わせフォーム>
http://www.trendmicro.co.jp/jp/contact/index.html#business

----------------------
エコシステムソリューション部 部長
パートナーソリューションアーキテクト
松本 大樹 

[ESP for AWS] POSITIVE on CLOUDiS／STAFFBRAIN on CLOUDiS (株式会社 電通国際情報サービス)

皆様、こんにちは。Parnter SAの井上です。3日連続のISID様のソリューション紹介も本日いよいよ最終日。最終日はHCMソリューション「POSITIVE on CLOUDiS／STAFFBRAIN on CLOUDiS」をご紹介させて頂きます。

【前日分までの振り返り】
　第1弾：PLEXUS CAE on AWS
　第2弾：STRAVIS on CLOUDiS

--

会社名:  株式会社電通国際情報サービス

製品 / ソリューション名: POSITIVE on CLOUDiS／STAFFBRAIN on CLOUDiS

会社 / 製品ロゴ:

 

システム構成図:

 

製品/ソリューション概要:

 

■製品 / ソリューション説明と特徴:

「POSITIVE on CLOUDiS」「STAFFBRAIN on CLOUDiS」は、1400社以上の導入実績を誇る統合人事システムパッケージ「POSITIVE」「STAFFBRAIN」のクラウド版です。パッケージの高機能はそのままに、従業員数やグループ会社数など利用規模の増加に応じて段階的なリソース追加を可能とする、AWSの特性を活かしたクラウドサービスです。

・POSITIVE、STAFFBRAINについて

「POSITIVE」は、人事・給与・就業管理に加えて、タレントマネジメント支援やグローバル人事など大規模な企業で必要とされる機能を標準搭載したパッケージで、高い業務適合率を誇ります。またSTAFFBRAIN は、人事・給与・就業の統合管理を低コストで実現する、中堅企業向けのパッケージです。

・システム運用の支援サービスAOSMS（ISID-AO Service Management System）について

株式会社電通国際情報サービス（ISID）のクラウドサービスは、単にソフトウエア（システム）をAWS 上で稼働させるだけではなく、システム運用の支援サービスを併せて提供します。ISIDグループの統合監視・運用管理システムサービス「AOSMS」による、24時間365日の監視・運用保守サービスに加え、セキュリティパッチ適用、法制度改定対応、バージョンアップ適用などをユーザーに代わって実施し、インフラの管理や運用負担を軽減します。

【POSITIVE画面イメージ】

対象ユーザーと導入効果:

人事・給与・就業管理やタレントマネジメントを別々のシステムで運用しており、人事関連情報の分散とシステム維持運用コストに課題があるユーザー様が対象。広範な機能を網羅した弊社統合HCMソリューションの導入により、ユーザー様の課題を解決します。AWSを組み合わせて使用することで、ハードウエア資産を保有することなく、適正なコストで最新のインフラが利用可能です。

システム要件/利用するAWSサービス:

■システム要件:（2015年5月現在）
・対応OS: Windows Server 2012
・データベース：Oracle 11g
・クライアント：
　Windows 8.1 / 8 / 7
　Excel 2013 / 2010 / 2007
　Internet Explorer 11.0 /10.0 / 9.0 / 8.0

■AWSサービス:
EC2, RDS, S3, VPC, ELB

AWSでの導入実績:
非公開

費用:
弊社までお問い合わせ下さい。

その他情報:
より詳しい製品説明はこちらにあります。
http://www.isid.co.jp/positive/

オプションサービスとして給与アウトソーシングを提供しています。
http://www.isid.co.jp/positive/solution/outsourcing.html

お問い合わせ先:
株式会社電通国際情報サービス
ビジネスソリューション事業部
TEL：
　東京03-6713-9123
　大阪06-6346-2011
　名古屋052-238-4571
http://www.isid.co.jp/positive/

[ESP for AWS] STRAVIS on CLOUDiS (株式会社 電通国際情報サービス)

皆様、こんにちは。Parnter SAの井上です。3日連続のISID様のソリューション、本日２日目の中日はAWSを使用した連結会計SaaSのソリューションである「STRAVIS on CLOUDiS」をご紹介頂きます。

第一弾：PLEXUS CAE on AWS はこちらからご参照ください。

--

会社名:  株式会社電通国際情報サービス

製品 / ソリューション名: STRAVIS on CLOUDiS

会社 / 製品ロゴ:

システム構成図:

 

製品/ソリューション概要:

■製品 / ソリューション説明と特徴:
STRAVISは、1984年以降から800を超える企業グループの業の課題解決を実現してきたノウハウと、経験を集積し、ご提供している連結会計システムです。制度連結だけでなく、管理連結、予算連結、IFRS対応等、幅広い業務で利用可能な、汎用性の高い機能で、お客様の業務効率化・高度化を支援いたします。今回ご紹介する「STRAVIS on CLOUDiS」は、STRAVISを、Amazon Web Services(以下、AWS)上でご提供するソリューションです。

ソリューションの特徴は下記の3点になります、

①IFRS対応 管理連結対応

複数会計基準への対応、多様な管理連結業務を単一のシステムで実現しております。常に最新の会計基準に準拠した制度連結決算環境を提供するだけでなく、制度連結と同一のモジュールで、月次単位での連結処理、予算数値（年初予算、見直し予算等）の連結処理等の管理連結業務を、同時並行で実施可能な環境を提供いたします。

②高い業務適合率

STRAVISは「制度連結業務だけでなく、多様な業務を吸収できること」「マニュアル処理の徹底的な自動化」を基本思想として開発されました。その結果、STRAVISは、他社の製品には見られない、驚異の業務適合率を誇っています。

③充実した保守サービス

制度改正対応、製品機能強化を目的とした継続的な製品バージョンアップ、決算期特別サポート体制の整備、豊富な研修ラインアップ、充実した各種マニュアルの提供等を通じて、お客様の安定的な業務継続を支援。充実の保守サービスをお約束いたします。

 

【STRAVISでサービス提供可能な機能マップ】

■対象ユーザーと導入効果:

STRAVISは、グループ経営の基本的インフラである連結会計システムとして、常に変化する経営環境下の経営判断に資する財務情報を、正確かつ迅速に提供致します。また、STRAVISは、数多くの導入実績に裏付けられた豊富な機能により、連結実務担当者の業務負荷を大幅に削減します。

【期待される効果】

【実務担当者のメリット】

 

システム要件/利用するAWSサービス:

■システム要件:（2015年5月現在）
・サーバ側:OS/Windows Server 2008 R2、2012 R2、
・クライアント側：OS/WindowsXP SP3、Microsoft Excel 2003以降

■AWSサービス:
EC2, EBS, S3, AMI, VPC, SES, (DirectConnect)

AWSでの導入実績:
連結会計ソリューション累計導入実績800社超、うち、AWS版利用社数約40社
http://www.isid.co.jp/stravis/case/

費用:
初期費用：個別御見積り
ライセンス費用：600万円～
別途基本料金およびオプション料金の設定あり。

その他情報:
詳細は下記弊社窓口までお問い合わせください。

サービス紹介URL:
http://www.isid.co.jp/stravis/

お問い合わせ先:
株式会社電通国際情報サービス　
ビジネスソリューション事業部
E-mail:[email protected]
TEL:03-6713-7101
FAX:03-6713-9923

[ESP for AWS] PLEXUS CAE on AWS (株式会社 電通国際情報サービス)

皆様、こんにちは。Parnter SAの井上です。本日から3日間はISID様のソリューションをご紹介させて頂きます。
本日は第一弾のPLEXUS CAE on AWSです。

製品 / ソリューション名: PLEXUS CAE

会社 / 製品ロゴ:

 

製品/ソリューション概要:

■製品 / ソリューション説明と特徴:

本サービスでは、マシン調達やアプリケーション設定など、解析に必要な環境構築作業は、ISIDが独自に開発したコントロールサーバーにより自動で行われます。そのためユーザーは、Web画面からの直感的な操作だけで、自社の解析ニーズに合ったHPC環境を調達し、すぐに解析作業を開始することができます。

ハードウエア利用料は、時間単位で使った分だけの従量課金制です。計算処理ごとの解析サイズに応じてサーバーを選択可能なため、必要な解析リソースを無駄なく活用でき、コストパフォーマンスの最大化を実現します。さらに、当月や累計の利用実績をWeb画面上で管理する機能を提供しており、利用料の上限やアラートの設定なども容易に行うことができます。

解析ツールは、機構・構造・流体・衝突など、主要な解析領域をカバーし、順次拡充し ていきます。ツールにより、持ち込み・レンタル・従量課金の3種類の課金体系を用意しており、またラインアップ以外のツールやユーザーの自社開発ツールに も、個別カスタマイズにより対応することができます。

 

■対象ユーザーと導入効果:

解析技術は開発コストの削減、期間短縮、現象解明など様々なシーンで利用されるようになり今では製品開発サイクルの中でも必須の技術といえます。しかし、利用する頻度やその時のニーズに応じた解析実行環境を用意するということは、費用面・構築期間を考えても不可能でした。PLEXUS CAEでは、クラウドコンピューティングのメリットを最大限に活かし必要な時にすぐに使える、使ったら使った分だけの利用費用を、簡単なインターフェースで提供することを実現いたしました。システムに業務を合わせるのではなく、製品開発のために本当に必要な計算リソースを最適なカタチで提供いたします。

システム要件/利用するAWSサービス:

■システム要件:（2015年5月現在）

・クライアント
　対応ブラウザ: IE8,9,10
　ActiveXコントロールとプラグイン：有効

・計算サーバとして利用可能なインスタンス
　m2.4xlarge , m3large
　cr1.8xlarge
　c3.4xlarge , c3.8xlarge
　c4.4xlarge,c4.8xlarge
※ソルバーにより利用できないものもあります。

■AWSサービス:
EC2 , VPC , Route53 , Elastic Load Balancing , Direct Connect
S3 , EBS , RDS , CloudWatch , IAM , SES , SNS

 

AWSでの導入実績:
・A社様　：　流体解析
・B社様　：　衝突解析
・C社様　：　機構解析

費用:
https://portal.plexusplm.com/plexus-cae/price

その他情報:
■購入方法:
アカウントを取得後、マイページよりお申込みが可能です。
https://portal.plexusplm.com/plexus-info

■その他情報:
セミナー情報等は以下のサイトにて随時掲載しています。
http://www.isid-industry.jp/

お問い合わせ先:
株式会社電通国際情報サービス　
エンジニアリングソリューション事業部　PLEXUS CAE担当

E-mail：[email protected]

ESP(Ecosystem Solution Pattern)カタログのソリューションカテゴリ

Partner SAの松本です。

先日、ESP(エコシステム ソリューション パターン)カタログをご紹介しました。

全320ページ、150以上のAWS対応ソフトウェア製品/ソリューション/SaaSが掲載されたカタログですが、下記のように16カテゴリに分かれています。

1. 業務アプリケーション [20製品]
2.  情報共有システム [17製品]
3. CRM/SFA [3製品]
4. BI [10製品]
5. データ分析/解析基盤 [13製品]
6. データ連携/ETL [10製品]
7. モバイル/IoT/M2M [7製品]
8. Webシステム [8製品]
9. メディア [3製品]
10. 運用監視/ジョブ [9製品]
11. HA/DR [3製品]
12. バックアップ/アーカイブ [5製品]
13. DB/ストレージ [7製品]
14. セキュリティ [19製品]
15. ネットワーク [10製品]
16. 開発基盤 [6製品]

 

上記カテゴリに分類される150以上の製品のAWS上での構成、対象ユーザーや効果、特徴、事例、ライセンス体系や費用などが分かりやすくまとまっている冊子です。

6/2-3に品川で開催されるAWS Summit Tokyo 2015のAWSブースにて無料配布する予定なので、早めに会場にお越し頂きお受け取りください！

----------------------
エコシステムソリューション部 部長
パートナーソリューションアーキテクト
松本 大樹 

AWS運用管理コミュニティについて

Partner SA酒徳です。

4日間に渡りセッションレポートを投稿させて頂きましたが、いかがだったでしょうか。今後もご要望の高いテーマをとりあげ運用管理フォーカスセミナーを継続予定ですので、是非ご参加頂ければと思います。運用管理フォーカス週間最終日となる本日は運用管理に焦点をあてたコミュニティのご紹介をさせて頂きます。

昨今多くのお客様、パートナー様からAWS上でのシステム運用についてご相談を受けます。今までオンプレミスで行ってきたシステム運用がそのままクラウドでも使えるのか、クラウド運用ならではの注意点がないのかを懸念されているお客様が多いのではないでしょうか。

本コミュニティは上記のような疑問を持たれるAWSユーザに対し、運用ベストプラクティスをまとめ、発信することを目的としており、APNパートナー様の有志の方々の協力のもと発足されました。現在は3社の方々に協力頂き活動をして頂いていますが、活動が軌道に乗り次第、オープンに広く参加者を募ったディスカッションを予定しています。一口に運用といいましても、監視やジョブ、ログ管理、構成管理と多岐に渡りますが、本コミュニティでは、運用対象システムを一般的なWeb 3 Tierシステムに絞り、下記運用カテゴリごとにベストプラクティスをまとめる予定となっています。

http://d36cz9buwru1tt.cloudfront.net/jp/architecturecenter/RefArch_WebApplicationHosting.pdf

運用カテゴリ

• システム監視運用
• ジョブ運用／停止起動運用
• ログ運用
• バックアップ／リストア運用
• コスト管理
• 構成管理
• 障害検知／通知運用

 上記、システム監視運用を例にとりますと、以下のような切り口で情報をまとめていく予定となっています。

• 死活監視
  • システムの死活状態の監視を目的に、AWSサービスの状態をどこまで監視するべきか
  • AWS Service Health DashboardによるAWSの状態をどのように監視するか

• 性能監視・キャパシティ監視
  • 性能監視
  • 短期的なサービスレベル確保とコスト低減を目的に、どのようなリソース情報を監視するか（アラートが必要）
  • キャパシティ監視
  • 長期的なリソース計画とコスト低減を目的に、どのようなリソース情報を監視するか（アラートが不要・情報収集のみ）
• AWSならではの監視と監視TIPS
• (CPU) CloudWatchから取れるメトリックスとOSから取れるメトリックスの使い分け
• CloudWatchの注意事項
• CloudWatchの保存期間
• CloudWatchの監視間隔（詳細モニタリングとベーシックモニタリング）
• CloudWatchと監視ツールとの使い分け
• T2インスタンス、gp2のバーストを考慮した監視
• メンテナンスイベントの監視
• Scalableなシステムの監視
• タグ付け監視
• CloudTrailによる操作ログ監視

プラクティスは準備ができ次第公開しますので、お楽しみにお待ち頂ければと思います。また来月開催されますAWS Summitでもブースを出されるパートナー様もいらっしゃいますので、ご興味のある方はブースにも足をお運び頂ければと思います。

　　　　　　　　　　　　　　　　　　　アウトプットサンプル

コミュニティ有志参加メンバー（※会社名の五十音順に掲載、今後順次拡張予定） 

株式会社エヌ・ティ・ティ・データ　澤井 健 様、長妻 賢 様

クラスメソッド株式会社　横田 慎介 様、高橋 勇輔 様

株式会社野村総合研究所　宮越 弘樹 様

 ------------------------------------------------- 
エコシステム ソリューション部
パートナー ソリューションアーキテクト
酒徳　知明