AWS CLIにオレオレwaitコマンドを追加する

aws cliには API 呼び出し後、特定のステータスになるまでポーリングする wait コマンドがあります。 例えば ec2 インスタンスを起動する API を呼び出し後、インスタンスの起動が完了するまで待つには $ aws ec2 wait instance-running –instance-ids xxx のようにします。 この wait 機能が実装されるまでは というように、ポーリング処理を自前で実装しなければいけ ませんでした(例外処理も真面目にやるとさらにごちゃごちゃする)。 この wait 系コマンドを独自追加する方法をメモ。 cloudformationでスタック構築完了を待つ 例として cloudformation でスタックの作成APIをたたいたあと (crete-stack)、スタックの構築が完了するまでポーリングするコマンド $ aws cloudformation wait stack-completed を実装してみましょう。 AWS CLI で wait を使わず cloudformation のスタックを構築 wait を使わずに cloudformation のスタックを構築するには $ aws cloudformation create-stack –stack [STACKNAME] でスタックの作製命令をし $

AWS Machine LearningのSchemaを自動生成する

やりたいこと AWS Machine Learning では学習・評価データのスキーマ定義が必要。 http://docs.aws.amazon.com/machine-learning/latest/dg/creating_datasources.html#creating-a-data-schema-for-amazon-ml マネージメントコンソールからデータセットを指定する時は、サーバーサイドでスキーマを推測してくれるがクライアントからAPIと叩く時は、スキーマは自分で用意しないといけない。 このスキーマ作成の作業を簡略化するために、AWS 中の人が作成したスキーマ推測ツールを利用してみる。 スキーマファイルの定義 まずはスキーマファイルのサンプルから 重要な属性は以下 rowId サロゲートキー このデータは学習には利用されず、予測結果も含めてリファレンス目的で利用。 dataFileContainsHeader 元データの1行目にヘッダー行が含まれていると true targetAttributeName 目的変数 attributeType データの各カラムのデータ型 カラム名とそのデータ型(NUMERIC/CATEGORICAL/TEXT/BINARY)で構成される。 詳細は次のURLを参照 http://docs.aws.amazon.com/machine-learning/latest/dg/creating_datasources.html#creating-a-data-schema-for-amazon-ml 最終的にはこの JSON 形式のスキーマをいい感じで自動生成したい。 スキーマを自動生成してみる github の次のレポジトリにある ml-tools-python ディレクトリにある guess_schema.py でスキーマを自動生成させる。 https://github.com/awslabs/machine-learning-samples にある ml-tools-python ディレクトリの guess_schema.py を使います。 ソースコードのクローン Python の AWS SDK である boto ライブラリが必要なので、インストールされていなければ $ pip install boto すること。 基本的な実行方法

Amazon Machine LearningのチュートリアルをAWS CLIから実行してみる

Summary “Amazon Machine Learning Developer Guide” には “Tutorial: Using Amazon ML to Predict Responses to a Marketing Offer” というこのサービスの初心者向けのチュートリアルが含まれている。 Tutorial: Using Amazon ML to Predict Responses to a Marketing Offer http://docs.aws.amazon.com/machine-learning/latest/mlconcepts/mlconcepts.html チュートリアルはマネージドコンソールから操作しているので、将来のスクリプト化を見据えて AWS CLI から操作してみる。 チュートリアルの流れ University of California, Irvine の Machine Learning Repository にある Bank Marketing Data Set を利用して、顧客が定期預金を契約するかどうかの 2 値分類を行う。 作業の流れは以下 Step 1:

[AWS]ELBのプライベートIPアドレスを調べる

Summary VPC 内にたてた ELB(internet-facing/internal) のプライベート IP アドレスをコマンドラインツールの AWS-CLI から調べる方法をメモ。 tl;dr : EC2 DescribeNetworkInterfaces を使う EC2 サービスには DescribeNetworkInterfaces という NIC 向けの API が存在する。この API を使うと ELB のグローバル/プライベート IP アドレスを確認できる。 NIC 一覧からお目当ての ELB を突き止めるには? ELB インスタンスの NIC の設定は aws が裏でやっているためか、ELB のNIC は Attachment => InstanceOwnerId が “amazon-elb” となっている。 また NIC の Description も aws が勝手に埋めており、“ELB “ となっている。

S3にBasic認証付きリクエストをすると400:Bad Requestになる

nginx で S3 にリバースプロキシしたサイトで、特定の URL 配下にしらーっとBasic認証を追加したら、S3 のリソースの取得が”400 : Bad Request” でことごとく失敗していた。 現象を再現させる まずはこの動きを確認してみる S3を用意 バケットを作成し、オブジェクトを public-read の ACL つきて PUT する。 public read が付いているので、anonymous user も GET できる。 Basic 認証付きでリクエスト 次に Basic 認証付きでリクエストしてみる みごとに 400 Bad Request エラーが発生した。 nginx での解決 nginx の解決策としては S3 にプロキシする際に Authorization ヘッダーを取っ払えばOK nginx_http_proxy_module には proxy_unset_header というディレクティブはなく、proxy_set_header でヘッダーの値をブランクにすると、そのヘッダーフィールドはプロキシされなくなる。

[AWS]マルチAZなElastiCache Redisの永続性についてメモ

Redis のデータを永続化させるには RDB : point in time スナップショット AOF : write ahead logging(WAL) の2種類の方法がある。 AWS ElastiCache Redis で Multi-AZ かつ自動フェイルオーバーなレプリケーショングループを組んでいる Redis での動きをメモ。 このようなレプリケーショングループの作り方は次のURLを参照 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoFailover.html Redis の RDB と AOF について RDB について RDB は point-in-time にダンプしたファイル。 通常の Redis であれば SAVE または BGSAVE(バックグランドで非同期に処理)コマンドで作成するが ElastiCache ではこれらコマンドは無効化されている。 ElastiCache では作成された RDB ファイルはスナップショットとして利用可能。 スナップショットファイルの作成は Replication Group 設定画面のバックアップ系設定で行う。 ElastiCache ではキャシュ処理とスナップショット作成のような管理機能がメモリーを奪い合わないように reserved-memory

[AWS]S3オブジェクトのHTTPステータスコードをカスタマイズして計画メンテナンスページを構築

計画メンテナンスでサイトを一時的に閉じる時、ブラウザでアクセスしてくる一般ユーザにはメンテナンスページを返せば十分だけれども、 検索ボットにはメンテナンスページの HTTP ステータスコードを 503:Service Unavailable で返すのが好ましい。 Official Google Webmaster Central Blog: How to deal with planned site downtime メンテナンスページは静的という前提のもと、AWS の DNS サービス route53 と CDN サービス CloudFront とストレージサービス S3 を組み合わせで実現してみる。 route53-ELB-EC2 というようなサーバ構成の場合、メンテナンスの前後で route53 の Alias Target を本番用の ELB からメンテナンスページ用の CloudFront にかえるだけで済む。 S3 の設定 メンテナンスページ用のバケットを作成。(名前は bucket-4-maintenance とする) メンテナンスページを 503.html というキーでアップロードする。 S3 バケットは検証しやすいように Static Website Hosting

AWS CLIを使ってマルチAZなElastiCache Redisのリードレプリカを作成する(お手軽版)

2014/10/24 の機能追加により、Redis はマルチAZ構成でノードを配置し、自動フェイルオーバーに対応した。 Multi-AZ Support / Auto Failover for Amazon ElastiCache for Redis http://aws.amazon.com/blogs/aws/elasticache-redis-multi-az/ 自分が知るかぎり、この機能が追加される前は異なる AZ に自前でクラスター配置しないとマルチAZにならなかったけど、機能追加後はマネージメントコンソールからボタンポチでマルチAZできるようになった。 このマネージメントコンソールの機能追加はコマンドライン aws cli (というかAPI)にも反映されているので、高可用性な Redis クラスターをサクッと構築してみる。 自前でゴリゴリやる手順は過去に書いた。 AWS CLIを使ってマルチAZなElastiCache Redisのリードレプリカを作成する https://siguniang.wordpress.com/2014/09/27/create-elasticache-redis-multi-az-read-replica/ 作業の流れ VPC & サブネットの作成 ElastiCache向けサブネットの作成 レプリケーショングループの構築 サブネットの作成 VPC に ElastiCache 用の異なる AZ のサブネットを作成。 これらサブネットを Cache Sbunet Group としてまとめる。 まとめたサブネットグループが foosubnet 2 つあるサブネットの SubnetAvailabilityZone が 1b と 1c

AWS CloudWatchにカスタムメトリックスを登録する

ゴール AWS のサービス(特に EC2)を監視するには aws マネージドサービスにデフォルトでついてくる CloudWatch を利用(aws おまかせ) カスタムメトリックスを CloudWatch に送信し、CloudWatch を利用(エージェントだけ自前実装) new relic のような ASP サービスを利用(エージェントだけ自前インストール) Zabbix などの監視システムを構築(サーバ、クライアントの両方を自分で面倒を見る) といった方法がある。 今回は2つ目の方法をメモ。 監視内容 EC2 インスタンス(OS は amazon Linux)からカスタムメトリックスを CloudWatch に送信する。 実験に使いやすいインスタンスに nginx がインストールされていたので nginx のメトリックスを送ることにする。 nginx のメトリックスを取得 ngx_http_stub_status_module モジュールを利用してメトリックスを取得する。 amazon Linux から yum でインストールする nginx でも利用可能。 $ nginx -V の出力結果に –with-http_stub_status_module があるのを確認できる。 server または location

cURLの出力結果をカスタマイズする

Chrome の Developer Tools→Network→Timing にはリソース取得の各ステップにかかる時間が俯瞰できるようになっていて、このデータへアクセスする JavaScript API も用意されている。 諸般の事情により、これと同等のデータを cURL を使ってコマンドラインから取得する方法をメモ。 というか、必要なことは次のブログにまとめられている Timing Details With cURL https://josephscott.org/archives/2011/10/timing-details-with-curl/ cURL デフォルトの出力 cURL デフォルトの表示は以下のようになる(レスポンスデータは -o オプションで /dev/null に捨てる) プログレスバーは -s/–silent オプションをつけると無効化できる。 出力のカスタマイズ 本題の出力メッセージのカスタマイズを行うには、フォーマットを記述したファイルを用意して -w/–write-out @format-file-name というオプションをつければ良い。 フォーマットの記述について 送受信の転送量やらHTTPレスポンスステータスやリダイレクト情報などいろいろな情報をとれるのだけど、Chrome にちかい指標は以下 time_namelookup : DNS Lookup タイム time_connect Initial : Connection / Connecting time_appconnect : SSL ハンドシェイク time_starttransfer : Time To