AWS Solutions Architect ブログ

Tech Hack-a-thonをやりました

AWSソリューションアーキテクトの蒋 逸峰(@uprush)です。

社内エンジニアが集まってTech Hack-a-thonをやりました。金曜日まる１日、緊急じゃない手先の作業を一旦置いといて、AWSを使って何か手を動かして作ることに集中しました。普段とれないまとまった時間をとって、皆で楽しく手を動かし何かを作ったり、トレーニングしたり、Dive deepすることが目的でした。

朝１０時に、集まったみなさんが作りたいアイディアをホワイトボードに書いて、あとは音楽を聞きながらコーディング！

 

コーディングに集中！

 コーディングに集中すると時間が経つのが早いですね。夜８時に発表タイムがやってきます。ビルやワインを飲みながら、一人ずつ発表やデモをして貰いました。

発表タイム！

コードを解説する@imai_factory

途中参加の方も居るなか、たくさんのアウトプットができました：

清水(@shimy_net)：LEDTシャッツ
渡辺(@gentaw0)：Workspaces boot camp slides
千葉：Sample AWS Management Console federation site with ADFS
吉田： Automatic VPN connection for vyos (Leap Motion持ってきたが、途中で故障し急遽VPNネタにした。。)
荒木(@ar1)：AWS Configでインスタンスに起きた変化を可視化する
今井(@imai_factory)：Kinesisアプリ
片山(@c9katayama)：名古屋cloud roadshowネタ検討（完成品1 完成品2, 完成品3）
大谷(@shot6)：DynamoDBのドキュメントAPI、JSON対応したから簡単なサンプルで紹介する
舟崎(@funasaki)：CodeDeployデモ&スライド
蒋(@uprush)：Reader -- Lambdaを使ったリアルタイム・キーワード抽出

今回はちょうどAWS re:Invent開催後の週末もあって、やはりLambdaなどre:Inventで発表された新しいサービスを使ったデモが多かったですね。

参加された方々、私自身も楽しくコーディングすることができました。アウトプットもあってHack-a-thonをやってよかったと思いました。これからも定期的にこのTech Hack-a-thonをぜひ続けたいと思います。

2014年12月のAWS Black Belt Tech Webinarのご案内

AWSソリューションアーキテクトの篠原英治(@shinodogg)です。

毎週水曜日18時からAWS Black Belt Tech Webinarを開催しております。12月は以下のラインナップでお届けします。ありがたいことに本セミナーにご参加いただいている方の人数は月を追うごとに増加しています。忙しい師走も時間を作ってBlack Beltと一緒に駆け抜けましょう！

• 12月3日(水)
• AWS Directory Service - 渡邉 源太
• セミナー参加登録リンク: https://www2.gotomeeting.com/register/615532258
• セミナー内容:
• AWS Directory Serviceは、AWS上でフルマネージドのディレクトリサービスを利用することができるサービスです。また、オンプレミスのActive Directoryと連携してAmazon WorkSpacesやZocaloなどの認証をおこなうことができます。今回のWebinarではActive DirectoryをAWS上で構築するためのベストプラクティスとあわせてAWS Directory Serviceの機能、代表的な使い方などをご紹介します。
• 12月10日(水)
• AWS CloudTrail & CloudWatch Logs - 酒德 知明
• セミナー参加登録リンク: https://www2.gotomeeting.com/register/798131042
• セミナー内容:

• CloudTrail & CWLはAWSで稼働するシステムの運用を支えるロギングサービスです。CloudTrailは今年の7月より東京リージョンで利用可能に、CWLは東京リージョンではまだローンチされてサービスですが既に多くのお客様からお問い合わせを頂いています。各サービスのご紹介はもちろん、ユースケース、今までお問い合わせ頂いたQAを中心にご紹介します。AWSロギングサービスの疑問を一気に解決しましょう!

• 12月17日(水)
• AWS CloudFront - 北迫 清訓
• セミナー参加登録リンク: https://www2.gotomeeting.com/register/769091914
• セミナー内容:
• CloudFrontは今年大幅なレポート機能の改善が行われ、CDNによるサイトのアクセス状況をより簡単に可視化できるようになりました。また、HTTPヘッダーの対応、セキュリティ機能の改善など、利用いただける領域も拡大してきています。今回のWebinarでは、CloudFrontのUpdateを中心に、CDNの活用についてご紹介させていただきます。
• 12月24日(水)
• クリスマスのためお休み
• 12月31日(水)
• 大晦日のためお休み

AWS Black Belt Tech Webinarは、Ctrix社のGoToMeetingで配信します。セミナーの申込みおよび参加方法に関しましては、こちら(http://aws.amazon.com/jp/webinar-flow/)に詳細を記載しております。iOSアプリやAndroidアプリもございますのでご活用ください。

また、こちらのセミナーの過去の発表資料は AWS クラウドサービス活用資料集 (http://aws.amazon.com/jp/aws-jp-introduction/)にございますので、是非ご覧ください！

 

今月の写真は、先日山中湖畔で撮影したソリューションアーキテクトの集合写真です。

AWS CloudTrail Processing Library

本日はAWS SDK for Javaに新しく追加されましたAWS CloudTrail Processing Libraryについてご紹介させて頂きます。

AWS CloudTrail は、AWS で実行された APIの履歴をログファイルとしてAmazon S3に保管します。AWS CloudTrail Processing Libraryを使ってアプリケーションを構築することで、AWS CloudTrailにより取得されたログの読み込みや、取り扱いが簡単に実装できるようになり、ビジネスロジックに組み込むことが容易になりました。たとえば開発者の方は、イベント元やイベントの種類に対してフィルターを設定できるようになりますし、またそれらのイベントをAmazon RDS、Amazon Redshift、もしくはサードパーティのデータストアに保管することも可能になります。

AWS CloudTrail Processing Library(CPL)を利用することで、Amazon SQS キューへのポーリングであったり、キュー に蓄積されたメッセージの読み込み・解析、CloudTrail ログ ファイルのダウンロードやログファイル内のイベントをパース、シリアライズするためにコードを記述する必要がなくなります。CPL を使用することで、開発者はわずか 10 行足らずのコードで CloudTrail のログ ファイルの読み込み、操作が可能になります。またネットワークタイムアウトやリソースへの一時的、もしくは長期的なアクセス遮断等の障害にも耐えうる耐障害性、回復性をもちます。スケール性に富み、並列に無制限のログファイルを処理できます。必要に応じ複数のホストから のCPLを実行に対し 、同じS3 バケット、同じ SQS キューの並行処理を行うことが可能です。

CPLは簡単にご利用頂けます。AWS 資格情報の設定と SQS キューを構成後、イベントに対し呼び出されるコールバックメソッドを実装し、AWSCloudTrailProcessingExecutorをスタートするだけです。

// This file contains your AWS security credentials and the name
// of an Amazon SQS queue to poll for updates
String myPropertiesFileName = "myCPL.properties";

// An EventsProcessor is what processes each event from AWS CloudTrail
final AmazonSNSClient sns = new AmazonSNSClient();
EventsProcessor eventsProcessor = new EventsProcessor() {
    public void process(List<CloudTrailEvent> events) {
        for (CloudTrailEvent event : events) {
            CloudTrailEventData data = event.getEventData();
            if (data.getEventSource().equals("ec2.amazonaws.com") &&
                data.getEventName().equals("ModifyVpcAttribute")) {
                System.out.println("Processing event: " + data.getRequestId());
                sns.publish(myQueueArn, "{ " + 
                    "'requestId'= '" + data.getRequestId() + "'," + 
                    "'request'  = '" + data.getRequestParameters() + "'," + 
                    "'response' = '" + data.getResponseElements() + "'," +
                    "'source'   = '" + data.getEventSource() + "'," +
                    "'eventName'= '" + data.getEventName() + "'" +
                    "}");
            }
        }
    }
};

// Create AWSCloudTrailProcessingExecutor and start it
final AWSCloudTrailProcessingExecutor executor = 
            new AWSCloudTrailProcessingExecutor
                .Builder(eventsProcessor, myPropertiesFileName)
                .build();
executor.start();

上記の例では、それぞれのイベントに対し EventsProcessor を実装します。そのイベントが ModifyVPCAttribute によるAmazon EC2 VPCを変更する操作の場合、コードがAmazon SNS トピックにメッセージをパブリッシュし、オペレーターはあるアカウントの VPC 構成に大きな変更を確認することができます。

このことからもCPLを使うことで、AWS  CloudTrailイベントをいかに簡単に扱うことができるかをご理解頂けるでしょう。ここまでEventsProcessor を利用し、CloudTrail イベントを操作するカスタム ロジックの作成方法について見てきました。さらにAWSCloudTrailProcessingExecutor を利用することで下記インターフェイスも制御することが可能になります。

・EventFilter を使うことで、処理すべき特定のイベントフィルター処理を簡単に実装することができます。たとえば、ある特定のリージョンまたは特定のサービスから CloudTrail イベントを処理する場合、EventFilterを使うことで簡単にそれらのイベントを簡単に選択することができます。

・SourceFilters を使うことで、イベントソースに固有のデータを使用してフィルター処理を行うことができます。この場合SQSBasedSource には、何度メッセージが送信されたか等のフィルタ ―リングのための情報が含めれています。

・ProgressReportersは、アプリケーション処理がどのように実行されたかをレポートできますので、アプリケーションを通じて進行状況を報告することができます。

・ExceptionHandlers は、イベント処理中に発生したエラーに対するカスタム エラーハンドリングを追加することができます。

AWS CloudTrail Processing LibraryのソースがGitHubのaws-cloudtrail-processing-libraryプロジェクトに公開されています。

<dependency>
	<groupId>com.amazonaws</groupId>
	<artifactId>aws-cloudtrail-processing-library</artifactId>
	<version>1.0.0</version>
</dependency>

皆さん、AWSの操作をトラッキングするのにどのようにAWS CloudTrailをお使いでしょうか。

Amazon Kinesisシリーズ(3) Kinesis Client Library for Pythonを使ってKinesis Applicationを作ってみよう

パートナーソリューションアーキテクトの榎並です。
今回は、前回のBlogで紹介したKinesis Client Library（Java版）のPython版であるKinesis Client Library for Python（以下、KCL for Python）について掘り下げたいと思います。
2014年10月21日にKCL for Pythonがリリースされました。本ブログでは、AWS Blogを補足する形で、KCL for Pythonについて説明していきます。

 

１．KCL for Python概要

KCL for Pythonは、KCL for Javaを使ってます。
ここが勘違いしてしまうポイントかもしれません。Amazon Kinesisからのデータ取得、ロードバランシングや可用性を高める機能などは、KCL for Javaを利用している構造です。データ取得後の処理ロジックをPythonで記述することができる構造です。これができるようになったのもKCL for Java version 1.2からMulti-Language Support機能がついたからです。このMulti-Language Support機能は、常駐プロセスとして起動し、サブプロセスとしてPythonで記述されたデータ処理用プログラムを起動します。常駐プロセスとデータ処理用プログラム間は標準入出力を経由してデータ連携がされる構造になります。
標準入出力間は、JSONフォーマットのプロトコルが定められています。詳細は、こちらをご覧ください。

２．サンプルコードの実行

上記の内容をご理解頂ければ、Githubに記述されている手順も容易に理解できると思います。
Githubに書かれている手順と重複しますが、以下の手順でセットアップします。

$ git clone https://github.com/awslabs/amazon-kinesis-client-python.git
$ cd amazon-kinesis-client-python
$ sudo python setup.py install

amazon-kinesis-client-pythonフォルダ内のsamplesフォルダ内にKCL for Pythonのサンプルアプリとデータを入力するためのアプリが容易されております。まず、Amazon Kinesisにデータを入力いたします。
sample_kinesis_wordputter.pyを実行することでデータを入力することができます。実行するためのクレデンシャルの設定（~/.aws/credentialsに記述する、IAMロール利用するなど）を行ってください。
sample_kinesis_wordputter.pyでは、指定したAmazon KinesisのStreamがなかった場合には、自動的に作成してくれるので便利です。（以下は、ap-northeast-1を利用する用にしております。）

$ cd samples
$ sample_kinesis_wordputter.py --stream words -w cat -w dog -w bird -w lobster -r ap-northeast-1

 KCL for Pythonのサンプルアプリ sample_kclpy_app.py を実行するために、まず、sample.propertiesに設定を行います。既にサンプルアプリが最低限動作ための設定はされているので、実行するKCL for Pythonのパスの設定と利用するリージョンをap-northeast-1に設定を以下の通り行ってください。

（５行目）
executableName = /home/ec2-user/amazon-kinesis-client-python/samples/sample_kclpy_app.py

（３４行目）
regionName = ap-northeast-1

上記、設定を行うことで実行可能になります。
先にも記述している通り、KCL for JavaがKCL for Pythonで記述されたプログラムを起動するので、KCL for Javaを起動することになります。起動時の必要なライブラリの指定など面倒な作業を簡易化するためにamazon_kclpy_helper.pyというヘルパープログラムがsamplesフォルダ内にあります。以下の形でコマンドを実行するとKCL for Javaを起動するためのコマンドがプリントされます。

$ amazon_kclpy_helper.py --print_command -j /usr/bin/java -p /home/ec2-user/amazon-kinesis-client-python/samples/sample.properties

/usr/bin/java -cp /usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/amazon-kinesis-client-1.2.0.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/jackson-annotations-2.1.1.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/commons-codec-1.3.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/commons-logging-1.1.1.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/joda-time-2.4.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/jackson-databind-2.1.1.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/jackson-core-2.1.1.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/aws-java-sdk-1.7.13.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/httpclient-4.2.jar:/usr/lib/python2.6/site-packages/amazon_kclpy-1.0.0-py2.6.egg/amazon_kclpy/jars/httpcore-4.2.jar:/home/ec2-user/amazon-kinesis-client-python/samples com.amazonaws.services.kinesis.multilang.MultiLangDaemon sample.properties

上記の出力結果を、コピーして、再度コンソールにペーストすることでKCL for Javaが実行されます。
実行すると、コンソール上にKCL for Javaが利用するAmazon DynamoDBのテーブル作成やAmazon Kinesisのシャードからのデータ処理ステータスなどが確認できます。

３．データ処理ロジックの実装

上記のサンプルアプリでは、肝心のデータ処理部分は何も実装されておりません。
kcl.RecordProcessorBaseの抽象クラスを継承して実装します。

initialize(self, shard_id)
process_records(self, records, checkpointer)
shutdown(self, checkpointer, reason)

initializeは起動時に1度実行されます。process_recordsは、複数回実行され、ここにデータ処理ロジックを実装することになります。shutdownは、KCL for JavaのMultiLangDaemonがシャットダウンしたときに呼ばれます。
KCL for JavaのMultiLangRecordProcessor.javaを見ていただくとわかるのですが、initializeメソッド内でデータ処理ロジック（サンプルだとsample_kclpy_app.py）のプロセスを起動し、processRecordsメソッド内で取得したデータを標準出力として書き込みを行います。データ処理ロジック側は常に標準入力を待っており、入力されたデータをチェックし、process_recordsに合致する内容であれば、データ処理ロジックのprocess_recordsが実行される流れになります。
KCL for Javaでは、Shard毎にWorkerが起動されるため、データ処理ロジックのプロセスもWorker数分起動される構造になります。

sample_kclpy_app.pyでは、95行目付近にロジックを入れることが可能です。

４．KCL for Pythonで指定できるパラメータ

sample.propertiesで設定できるパラメータは、以下の通りです。基本は、KCL for Javaで指定できるパタメータになります。

項目	内容
failoverTimeMillis	Workerが処理を継続できなくなり別なWorkerにフェイルオーバする時間（ミリ秒） 短い値を設定するとDynamoDBのPIOPS高くなるため注意が必要
maxRecords	1回のデータ取得で取得するレコード件数
idleTimeBetweenReadsInMillis	レコード取得間隔（ミリ秒）
callProcessRecordsEvenForEmptyRecordList	レコードデータが空でもレコード取得処理を継続するかの判断（True or Fault）
parentShardPollIntervalMillis	親のShardをチェックするインターバル 短い値を設定するとDynamoDBのPIOPS高くなるため注意が必要
cleanupLeasesUponShardCompletion	shradが終了した後に継続して処理を続けるかクリーンアップするかを指定
taskBackoffTimeMillis	KCLのバックオフタイムの設定
metricsBufferTimeMillis	CloudWatchのAPIコールする前の時間
metricsMaxQueueSize	CloudWatchのAPIコールする最大のキューサイズ
validateSequenceNumberBeforeCheckpointing	Checkpointingする前にシーケンス番号をチェックするかを指定
maxActiveThreads	MultiLangDaemonの最大スレッド数

 

Javaでの実装にハードルがあった方には、今回のPython対応はメリットがあるかと思います。また、KCL for JavaがMulti-Language対応されたので、今後、Python以外での実装も容易になったかと思います。

ぜひ、色々なKinesisアプリケーションを作成してください。

 

AWS環境におけるERP市場の現状と今後

パートナー ソリューションアーキテクトの松本です。 

今回は最近AWS界隈で急速に進んでいるERP on AWSについてのご紹介になります。今までもセミナーや利用事例などでSAP社、Oracle社、Microsoft社、WorksApplicaions社、SuperStream社などの製品を使って、エンタープライズ企業の基幹システムをAWSに移行・構築するユーザー様が多くいらっしゃることをご紹介してきましたが、その流れを受けて名立たるERPベンダー様達がAWSでのビジネス展開を表明頂いています。この回ではAWS上のERPの状況がどのようになっているのかの全体像を把握頂ければと考えています。

そもそもERPとは何なのか？細かい話はその手の専門家に任せるとして、ざっくり説明するとEnterprise Resource Planningの略語で、エンタープライズ企業が効率的に活動できるように人・物・金という資源を上手く管理して有効活用していくためのツールになります。このような性質から「ERPシステムが停止すると企業の活動が停止する」と言われ、所謂“基幹システム”と位置付けられる事が多い業務システムの1つです。管理会計、連結会計、人事管理、販売管理、物流管理、生産管理など、対応業務領域は多岐に渡り、製品ごとに特徴がありますので、ユーザーが必要となる要件を満たすパッケージを選択してご利用頂く形になります。

現状AWSで利用可能な、日本で良く利用される代表的な業務パッケージとしては下記があります。下記の製品名は一例になりますが、皆様がお使いの製品や、お付き合いのあるベンダー様も含まれているのではないでしょうか。

 

ERPベンダー名	代表製品
SAP	SAP Business Suite
Oracle	Oracle EBS, Hyperion, JD-Edwards, Siebel, People Soft
Infor	Infor CloudSuite, Infor LN, Infor M3, Infor SyteLine
Microsoft	Dynamics AX
WorksApplications	CCMS(COMPANY), HUE
SuperStream	SuperStream NX
OBIC	OBIC7
OBC	勘定奉行シリーズ
GRANDIT	GRANDIT
NTT DATA	Bizインテグラル, Imtra-mart
ISID	Positive, STRAVIS
SCSK	ProActive
ディーバ	DivaSystem GEXSUS
日立システムズ	FutureStage

 

数年前にはAWS対応製品は殆どありませんでしたが、現在ではグローバルで展開されている製品から国産ベンダーにより日本企業向けに最適化された製品まで幅広いラインナップをAWS上でご利用頂くことができるようになりました。 

またサポートされるAWSサービスも増えて来ています。例えばSAP社では認定インスタンスという制度がありますが、日々SAP本社のドイツにて認定されるAmazon EC2のインスタンスタイプは増えており、どんどんユーザーが利用しやすい環境が整って来ています。最近ではC3/R3インスタンスが新たに認定インスタンスに追加されました。(http://aws.amazon.com/jp/sap_japan/) 

SuperStream社も最近のプレスリリースにて、同社のERP製品のAmazon RDSでの動作検証の完了と正式サポートを表明しています。(http://www.superstream.co.jp/file.jsp?id=14450)

今後もAWS対応製品や対応するAWSサービスは増えていく予定になっており、AWS上でのERP利用はより便利になっていくでしょう。

 

利用されるテクノロジーにも徐々に変化が出てきています。長い間、Oracle DatabaseやMicrosoft SQL Serverという商用の既存RDBMSを利用する製品が殆どでしたが、独自のデータストア技術を開発・提供しているベンダーも出始めています。例えばSAP社はHANAというインメモリーデータベースを提供しており、カラムナ型/ロー型の両方のエンジンを持っている上、スケールアウトによる拡張性も兼ね備えており分散型のクラウドアーキテクチャに適しています。WorksApplications社も新しいHUEという製品では独自のデータベースアーキテクチャを開発・採用すると発表しておりCloud Nativeを謳っています。 

また、AWS上で提供されるERPのサービス形態も大きく分けると下記に分類することができます。なお、これは各社の製品思想によるもので製品の優劣ではありませんのでご注意ください。

• EC2構築型
  • オンプレミス環境と同じようにEC2上にシステムを構築していく形態です。アーキテクチャ的にはオンプレミス環境と大きく変わりませんが、従量課金やオンデマンドなキャパシティ確保、複数データセンター利用による可用性の向上などのクラウドのメリットを享受することができます。殆ど全ての製品はこの形態で稼働可能です。

• EC2 & Managed Service複合構築型
  • EC2に加えてELBやAmazon RDS、Amazon DynamoDBなどのManaged Serviceを使用したアーキテクチャになります。一般的な構成としてはロードバランサ部分にELB、アプリケーションサーバ部分にEC2、データベース部分にRDSという形です。Managed Serviceを活用することによって、構築スピードの向上や拡張性、高可用性、自動化 など、より多くのクラウドのメリットを享受できます。SuperStream社はRDS対応を表明しています。

• SaaSシングルテナント型
  • SaaS形態ではERP環境の構築から運用管理まで一貫して提供することで、ユーザーは業務にフォーカスすることができます。シングルテナント型ではユーザー毎に環境を構築してサービスを提供する形になります。分離レベルはサーバーレベル(EC2, RDSなど)やネットワークレベル(VPC)など幾つかの形態に分かれますが、提供ベンダーによっては 利用ユーザーごとに運用や構成などにある程度の自由度が持てる場合があります。日立システムズ社のFutureStage for AWSやWorksApplications社のCCMS、ISID社のSTRAVISなどが該当します。

• SaaSマルチテナント型
  • システム全体のEPRリソースプールを複数のユーザーで共有利用するような形態です。基本的には利用コストが低い場合が多く、ユーザー視点からはSaaSシングルテナント型と比べERP機能自体の使い勝手は殆ど同じですが、運用や構成へ個別リクエストは基本的には対応できません。これらの条件も提供ベンダーによって異なります。Infor CloudSuiteはこのタイプのSaaSをAWS上で提供しています。

• クラウドネイティブ対応型
  • 既存のアーキテクチャを見直し、 クラウドの特徴を最大限に活かす為に新たにクラウドに最適化されたERPシステムです。このシステムで利用されるAWS サービスも様々です。これは今後増えてくると予想されるタイプで、ライセンス等も含め提供形態は多岐に渡ると思われます。WorksApplications社のHUEはこれに該当します。

このようにエンタープライズの特に基幹システムと呼ばれる領域において、技術的観点でのクラウド最適化が急速に進んでいます。ERPシステムはここ数年それほど大きなアーキテクチャの変更がされませんでしたが、クラウドの登場によってERPベンダー各社はそのメリットを活かす為の取り組みを色々な形で開始しています。この基幹システムといわれる領域で大きな技術革新が訪れる日はそう遠くは無いかもしれません。