2013memorycraft更新とか絶対忘れるから。2013年12月11日水曜日AutoScalingってなんじゃ?(AutoScalingがAWSマネージメントコンソールで管理可能に!)ついにAWSの管理コンソールからAutoScalingが管理可能になりました。EC2のコンソールの左ペインの最下部にAutoScaling(以下AS)の項目が追加されています。Group」をクリックします。既存のLaunchConfiguration(以下LC)を使うか、新規にLCを作るかを聞かれるので、今回は新規LCを選びます。すると、LC作成ウィザードに切り替わり、インスタンスの起動にまつわる設定が始まります。AMIインスタンスタイプ詳細設定ここで、LC名を入力します。それ以外はインスタンス起動の詳細設定と同じです。configuration」をクリックすると、LCの作成は終了で、自動的にASの作成に移ります。基本設定AS作成画面では、先に新規作成したLCまたは既存から選択したLCがセットされ、AS名やサイズ、起動場所(VPCやゾーン)、バランサのヘルスチェックなどを入力します。次にスケーリングポリシーを設定します。アラームや増減の限界値や単位を設定します。alarm」でその場でアラーム設定が可能です。ASのイベントとそれが発生した時の通知先を設定します。group」をクリックして設定を終えます。一覧画面に作成したばかりのASが表示されます。「Edit」で設定の変更が可能です。desired=1にして、1つインスタンスを起動してみます。すると、「ScalingHistory」タブでスケーリングイベントの履歴が確認できます。失敗イベントはその理由も記述されているので簡単なデバッグも行えます。インスタンス一覧を見てみます。正常に起動しているようです。いままでASはコンソールからはまったく見えませんでしたが、これで視認性がよくなりました。これからもコマンドライン等で設定を行うという人も、状態の確認などはコンソールを使うと便利かもしれません。2013」12/9用の記事です。前回、前々回でKinesisを触りました。DynamoDBなどの他に、別のKinesisストリームもありえるということを知りました。処理の内容が単純、高速であったり、データ数が少ない場合には1つのConsumerで事足りると思いますが、あまりにも大量であったり、処理の幾つかに非常に時間の掛かるものがあったり、複合的な処理が必要な場合には、複数のストリームを使うと全体の効率が上がる場合があるかと思います。Chainパターンの派生的なものになるかと思います。そこで、別のKinesisストリームに流すにはどういう場合が有効かを考えてみました。Chianパターン・統計的な処理を連続して行う場合、Producerが投入したデータ単位と、1つ目の処理が終わったデータ単位が異なる場合があります。その場合も1つ目が終わったときに別のストリームを使います。・処理全体の中で、負荷の高い部分と低い部分を分けて別に処理を行うことで、コストの最適化を行うことも考えられます。・共通処理もあるが、データの種類によって個別の処理が必要という時も別のストリームを使える場合があります。・おまけ:JettyをProducerにして、3つストリームのチェーンを使うと、ジェットストリームアタックになります。最後のが言いたかっただけでした。kinesis2013年12月4日水曜日Kinesisってなんじゃ?(Java実装編)前回からの続きです。このストリームをつかってイベント処理を行うアプリケーションを実装します。Kinesisを扱うには、現時点でJavaのSDKとKinesisのクライアントライブラリ(KCL)が利用可能です。今回のサンプルとなるシステムですが、以下のように定義してみました。y)を日時ごとにJSONとしてストリームに入力していきます。ConsumerAではストリームからデータを受け取り、ログとしてS3のバケットに保存していきます。ConsumerBでは同じくストリームからデータを受け取り、ユーザーごとの総移動距離をDynamoDBにインクリメント保存していきます。これを、限定公開用にKinesis対応されたJavaのSDKとKinesisのクライアントライブラリ(KCL)を使って実装してみます。SDKにはサンプルコードなどが付属しているため、それを参考に実装してみます。KCLはシャードの管理のために裏側でConsumerごとにDynamoDBテーブルを使用します。JDKの1.7とantがインストールされていることが前提です。Producer以下のツリー図の通り、SDKのサンプルコードの一部として他のサンプルと同じようにMemoKinesisというサンプルをつくりました。../../third-partyにクラスパスを通して、コンパイル→実行するようなターゲットになっているため、クラス名だけ変更してそのまま利用しています。AwsCredentials.propertiesには自分のアカウントのキー情報を入力してあります。このコードで必要なライブラリは../../libディレクトリに追加してあります(青字)。コードは以下の通りです。JSON化してストリームに投入しつづけます。AmazonKinesisClientを初期化し、PutRecordRequestを使ってputRecordします。実行すると以下のように投入され続けていくことがわかります。A次はConsumerです。これも同じように他のサンプルコードとほぼ同じ構成で実装しました。Aのインスタンス群では、ストリームに流れているデータを抽出して、順次S3にログとして保存していきます。ConsumerではKCLを使用します。構成としては、MemorycraftKinesisLoggingConsumerからIRecordProcessorFactoryを実装したMemorycraftKinesisLoggingProcessorFactoryを初期化してワーカーとして実行します。実際の処理はIRecordProcessorを実装したMemorycraftKinesisLoggingProcessorのprocessRecordsメソッド内部に記述します。MemorycraftKinesisLoggingConsumer.javaMemorycraftKinesisLoggingProcessorFactory.javaMemorycraftKinesisLoggingProcessor.java実行してみます。08:41:04","user_id":"testuser_F","x":"19.924814432111905","y":"41.65256488223227"}..........うまく拾えているようです。S3のバケットを見てみます。おお、次から次へとファイルが保存されていくのがわかります。そのうちの一つをダウンロードして、中身を見てみます。08:44:17","user_id":"testuser_H","x":"79.49199108301805","y":"2.4829017202529724"}中身もうまく入っているようです。B次はConsumerBです。Bのインスタンス群では、ユーザーIDをハッシュキーにしたDynamoDBのレコードにXとYから距離を出してインクリメントしていき総距離を加算更新します。クラスとしてはMemorycraftKinesisDistanceProcessorを中心に実装します。MemorycraftKinesisDistanceConsumer.javaMemorycraftKinesisDistanceProcessorFactory.javaMemorycraftKinesisDistanceProcessor.java実行してみます。distance:76.62457919060493].....それではDynamoDBを見てみます。ユーザーごとに集計されているようです。チェックポイントKinesisのコンシューマーでKCLを使うとコンシューマーごとにチェックポイントというマーカーを打つことができます。IRecordProcessor.checkpointメソッド内で、checkpointer.checkpoint()を呼び出すと、ストリームのシーケンスのなかでどこまで読み込んだという記録が保存され、読み取りを中断したり障害が起こった後に、プロセスを再稼働すると、そのチェックポイントから読み取りが再開されます。チェックポイントを呼び出すタイミングはユーザーに委ねられていて、今回のサンプルでは1分に設定しています。}わかったこと定期的ではなく常にデータ処理を処理し続けることができる仕組みと、そのためのスケーラビリティを持っている。ユーザーが書くコードは、最低限であればそんなに多くない。バッチではタイムラグがありすぎる!という場合にはうってつけのサービス。Consumer同士の処理順を気にしないでいい。処理順をつけたい場合は、そのConsumer内で行うか、出力先に別のストリームを指定しそちらで次の処理をするとかDynamoDBと同様、ストリームのキャパシティの見積もりは必要です。kinesisKinesisってなんじゃ?(ストリーム作成編)AWSの新サービスKinesisが限定プレビュー公開されています。私のところでも見れるようになったので、触ってみました。KinesisとはKinesisは大量なデータのリアルタイムイベント処理をサポートするサービスです。ユーザーは「ストリーム」を作り、そこにデータを流し、受け取り、処理を行います。データを流す、受け取る、処理を行う、という部分はユーザーがプログラムで実装します。Kinesisに接続するプログラムには大きく分けてProducerとConsumerという2つの立場があります。Producerはストリームにデータを入力します。Producerは場合によってWEBまたはAPPサーバーのようなエンドポイントであったり、既存データのフェッチプログラムとして実装されます。Consumerはストリームからデータを受け取り処理します。Consumerは処理内容ごとにAutoScalingグループなどによってクラスタ化されることが多くなります。ストリームを流れるデータは順序付けされたシーケンスとして扱われ、「シャード」に分散されます。Kinesisではシャードの単位でスループットが決定され、ユーザーは入出力の量に合わせてシャード数を設定できます。ストリームの作成それでは、まずストリームを作ってみます。限定公開なので、コンソールのメニューには現れませんが、申請が通っている場合は、以下のURLでアクセスできます。Stream」をクリックして、ストリームを作成します。ストリーム名とストリーム数を入力します。ストリーム数の目安がわからない場合は、DynamoDBと同じように、データサイズや書込回数、Consumer数を設定することで自動的に最適なシャード数を適用できます。「Create」をクリックすると、作成中(CREATING)のストリームが一覧に表示されます。Statusが「ACTIVE」になると利用可能です。ストリーム名をクリックすると、ストリームのメトリクスが表示されます。これをもとに、SDKなどでシャード数の変更などを行うことができます。料金シャード:1シャードあたり1時間0.015ドルリクエスト:100万PUTで0.028ドルデータ転送(入力):無料データ転送(出力):EC2で処理する分には無料これとは別に、実際の処理を行うEC2のインスタンス料金が掛かります。ストリームの料金ではなく、接続するEC2の料金で回収するモデルのようです。次回は、ストリームを使った実装をやってみます。kinesis2013年11月16日土曜日re:Inventってなんじゃ?(CloudTrail)re:Invent2013に来ています。そこでCloudTrailの発表があったので触ってみました。CloudTrailは、AWSのAPIコールの記録をS3にログとして保存するサービスです。これによってセキュリティ分析や運用チェックなどを行うことが可能です。AWSコンソールをみるとCoudTrailが追加されているので、開いてみます。ログの保存先のS3バケットを指定して、必要であればその他のオプションも設定します。Subscribeボタンを押すと、設定完了です。AWSの操作をしたあと、出力先に設定したS3バケットを確認します。すると、以下のように、json形式のログファイルが圧縮された状態で日ごとに保存されるようになります。このうちの一つをダウンロードして中身を見てみます。]}このように呼び出したAPIの内容が表示されるため、jqやログ解析ツールなどと併用してAWSアカウントに対してどういった操作があったかを簡潔に知ることが可能になります。Roleでディスク暗号化鍵をS3で管理)EBSの暗号化の方法のひとつとしてcryptsetupという技術があります。cryptsetupはパスフレーズで暗号化されたディスクにアクセス(マウント)しますが、今回は鍵ファイルを使用してアクセスする手順をまとめました。鍵ファイルを同じインスタンス内に置かないためにS3から鍵ファイルを取得し、マウントした後に削除するようにします。それでは手順を追ってみます。cryptsetupで/dev/xvdfにアタッチされたEBSボリュームの暗号化を行い、マウントします。/root/encrypted_keyS3バケットを作成し、そこへ鍵を保管します自動で暗号化+マウントするために起動スクリプトをつくり、S3から鍵ファイルを取得しマウントするようにします。終わったらAMIを作成します。Roleを指定しますこれで、鍵がない状態ではEBSをマウントすることができなくなりました。s32013年6月15日土曜日Spiderってなんじゃ?(SUBPARTITIONで負荷分散しながらストレージ容量を無限追加)Spiderシリーズです。Spiderではパーティションを使ってシャーディングしますが、パーティションの定義によって分散の特性が変わります。理想は均等に負荷分散しながら、データ容量を後から増やせるのがベストですが、1,2,3とも負荷分散と容量追加のどちらかにしか親和性がありません。SpiderでもSUBPARTITIONが使えるとのことでRANGEとHASHを組み合わせることで実現できると教えて頂きました。));まずRANGEパーティションをidの値の範囲で定義します。試しに1000000,2000000に設定します。次に、SUBPARTITIONでidでHASHパーティションを定義し、ここにデーターノードを指定します。db4に均等に分散されます。idが2000000を超えそうになった場合は、後から3つめのパーティションを追加することができます。));これでデータ容量はほぼ無限に増やすことができます。パーティションごとにSUBPARTITIONの数を変えることはできないので、負荷の分散数は同じデータノード数で賄わなければいけませんが、その場合はパーティションごとのデータノードのインスタンスタイプやPIOPSを増やすことで処理能力をアップさせることで対応できるかと思います。斯波さんありがとうございました!以上です。spider2013年5月28日火曜日Fluentdってなんじゃ?(設定ファイルをリモートから読み込む)fluentdのドキュメントに以下のような記載がありました。http://example.com/fluent.conf最後の行、、、HTTPから設定ファイルを取得してインクルードできるみたいです。いうことで試してみました。</match>これをS3にアップロードしてWEBホスティングしてみます。EC2では以下のように設定します。(再起動は必要ですが、定期的に再起動をかけるようにしておくという手もあります)いっそ全設定を外出しして完全に外部で管理するなどが可能になります。s32013年5月25日土曜日spiderってなんじゃ?(spider自身の冗長化)いままではSpiderがひとつに対して、データノードが複数ある構成をとってきましたが、実戦ではSpiderが単一障害点になるため好ましくありません。ここではSpider自身の冗長化を行なってみます。構成に対してデータを入れ込むためのappノードを用意します。10.0.1.20.......................................Spiderノードで投入されていることを確認します。