クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2015年3月21日
から hiruta
『Amazon Redshift』での本格データ分析~ここまで来た、クラウド型DWH~セミナーに参加しました。 はコメントを受け付けていません

『Amazon Redshift』での本格データ分析~ここまで来た、クラウド型DWH~セミナーに参加しました。

『Amazon Redshift』での本格データ分析~ここまで来た、クラウド型DWH~セミナーに参加しました。

Amazon の松本様からRedshiftについての話

  • Redshiftは2PBまで使用できる。(これ以上使いたい場合は、相談に応じるとのこと)
  • Redshiftは縦指向。RDSとは異なる。集計に最適
  • S3からRedshiftにロードさせるのが基本的な使い方
    • Lambdaを使うことでイベントトリブンでロードする方法も可能だが、S3にcsvなりデータ取り組むとで、データがRedshiftにロードできてしまうので、変なデータが置かれてもデータがロードされてしまうことが起こりうるので、気をつけないといけない。Lambdaのスケジュールトリブン(スケジュールによるイベント発火)が望まれる。

ウルシステムズ 吉田悦万様からデータ分析システム導入のポイントについて

 

ウルシステムズが提供している、オールインワン型のクラウドDWH Whte-eYeの紹介から

お客様ごとに要件を合わせて提供

 必要なAMIを組み合わせて短期間で構築

 事例として、ショッパーインサイトの「 POSデータの分析システム」で移行前だと以下問題を抱えていたのをクラウドに移行することでどう解決したかの話

  • 大量のデータだとパフォーマンスがでないとか
  • オンプレで運用していたのをクラウドに移行
  •  データ量が多い。パフォーマンスがでない →3,000億件
  • チューニングで対応
  • 可用性の要件が高い →自社内でやることが多い。信頼性の高いシステムが求めれていた
  • 負荷も考慮
  • 複雑で多様な要件 バスケット分析とか多様な分析

 フラストレーションが溜まっていた。

 

次に、分析システムを導入する場合のポイントについての話

  • 経営層を説得できない

→投資対効果が見えにくい。

  • 競合他社の動向を説明し、ホラーストーリーで説得

→スモールスタートする企画

→システムのライフサイクルを踏まえたコスト比較

→クラウドのコストメリット 3,4,5年を見据えて。オンプレだとインフラのマイグレーションとの比較も含めてコスト比較のがいい

 BIG DATA LANDSCAPE (→ここ

→BIG-Dataはコンポーネント(部品)が多岐に渡っている

  • 使ってみるのがよりよいものを見つけるのがオススメ
  • パフォーマンスが出ない

ある程度は、チューニングをしなくても出ますが、データ量が多くなるとチューニングは必要になる

チューニングすることで、処理も速くなり、リソースの使用時間も減る。つまりは利用料にも跳ね返ってくる

  • チューニング

Sortkey カーディナリティの低いものに有効

ディスクの利用率などて適切な圧縮エンコーディングで

 Distkeyは、データを投入してから検証

 分散されているか指標があるので、データ投入後に確認する

  •  データ連携の開発が時間がかかる

共通部品を作って開発をするのがポイント

  •  Cloudwatchだけでは不十分、あるスライスの容量は監視できない
  •  ディスク容量のサイジングミス

定期的にVACUUM使わないと

多量のデータ扱っているとそんなにVACUUM時間がかかるのでそんなに実行できないSELECTのサブクエリー

メモリに展開できない場合、ディスクフルのエラーが発生する

 十分容量を確保した設計が重要

ロングランテスト。ディスク容量のグラフ化

 列数が多いテーブルでVACUUMを実行するとエラーになる可能性がある

 ERROR 1036 DETAIL: Vacuum clumn limit exceded

→VACUUMの間だけ、wlm_query_slot_count の値を上げる

 本番機のパラメータを変えたくないので、DEEP COPY でこれで解決しているとのこと

  •  PostgreSQL 8.xのJDBCドライバーを使うと、21億件を超える行数を更新するとエラー
    • PostgreSQL 9.x系のドライバを使うことで解決

2015年2月11日
から hiruta
0件のコメント

AutoScalingによるサーバー復旧時間

AutoHealing by AutoScalingで自動復旧の仕組みを取り入れていますが、ちゃんと復旧時間を計ったことがありませんでしたので、ulimit及びFluentdのfluent-plugin-bigqueryのパラメータをいじるタイミングがありましたので、簡単に計測してみました。

ELB heath checkを予め以下で設定してあります。

screencapture-ap-northeast-1-console-aws-amazon-com-ec2-v2-home

タイムチャートは以下となりました。

2015 February 11 09:38 nginx stop
2015 February 11 09:40 unheathly
2015 February 11 09:40 Terminating EC2 instance – Waiting For ELB connection draining
2015 February 11 09:40 Terminating EC2 instance
2015 February 11 09:41 Launching a new EC2 instance

Connection Draingは、60秒にしています。

5分以内には復旧が見込まれる結果に。自動復旧する場合は、ELB heath checkを推奨。(EC2 heath checkだとAutoScaling発動までかなり待たされる)

2015年2月8日
から hiruta
0件のコメント

Google BigQueryの性能について実ログ(アクセスログ)で試してみました。

2/7 に行われたdots. Summit 2015のGoogle 佐藤さんの『大規模並列検索サービスGoogle BigQueryについて』でも話されていたのですが、Google BigQueryはインデックスを使わず、Googleの数百のサーバーで並列に処理してQuery結果を高速に返えせる。

他クラウドのデータウェアハウス製品の例を挙げると、dw1.8xlargeでも最大100まで。これを見るだけでもGoogle BigQueryはコストパフォーマンスはいいことがわかる。

また、正規表現で使った抽出も、高速とのこと。

そこで、個人ブログのnginxのアクセスログをfluent-plugin-bigqueryでGoogle BigQueryにインサートするデータでどの程度のものか試してみました。

※nginx_datasheet.access_logには、272,427件ほど入っています。

SELECT ua,  count(*) as count FROM [nginx_datasheet.access_log] WHERE REGEXP_MATCH(ua, r'.*Windows.*') GROUP EACH BY ua;

アクセスログのUser AgentにWindowsが含まれるレコードは、624件を以下の通り、4sで返してくれる。

Query complete (4.2s elapsed, 26.3 MB processed)

また、Google Cloud PlatformのVMインスタンスは、ライブマイグレーション対応しています。※AWSでは、最近us-east-1限定で対応したばかり。

2015年1月18日
から hiruta
0件のコメント

EC2 Auto Recoveryを試してみました。 #aws

ホストの障害を検知して、別のホストにマイグレーションすることができるEC2 Auto Recoveryは、US東海岸リージョンで使えるようになったので、実際試してみました。関連リリース記事はこちらになります。

これで、GCP ( Goolge Cloud Platform)のライブマイグレーションと似たことがAWSでも。ライブマイグレーションができれば、昨年末のXeon セキュリティパッチによるリブート祭りでも対応できるのでは。

1-0

 

Auto Recovery のドキュメントによるとEBS ストレージを使っているインスタンスに限定されるとなっています。

他にも、新しめのインスタンスのみ(c4シリーズは現時点では対応リストに入っていない)など制限事項があります。詳しくはこちらを。

  • Instances that use Amazon EBS storage exclusively.

インスタンスストアとしてswapが使われています。

[   37.962432] Adding 4188668k swap on /dev/xvdb.  Priority:-1 extents:1 across:4188668k SSFS

Swapをインスタンスストレージに使っているインスタンスのEC2 Recoveryを発動させてみました。StateがAlarmになった場合、発動させるようにしますが、それではホストが障害がなければ発動しませんので、疑似障害のために、INSUFFICIENTになったときに発動させるようにしました。

1-1

下記の通り、リカバリが失敗しました。インスタンスストアを使うインスタンスのリカバリができない結論か。

1-2

念のため、インスタンスストア(ephemeral disk)を使わないインスタンスのリカバリは、正常に終了しました。

1-3

 

結論インスタンスストアを使うとNGか。

2015年1月18日
から hiruta
0件のコメント

Docker Meetup #4に参加してみて

昨日Docker Meetup Tokyo #4に参加してきました。セッション×7、LT×8と中身の濃い半日でした。

CoreOS、dockerの性能劣化に関する話、Kubernetes(GKE)、ECSなどコンテナ管理するサービスの話、Cgroupによるコンテナリソースの制限、コンテナモニタリング(Datadog)、docker専用OSであるRHEL (CentOS) Atomic Hostの話、dockerのプロダクション環境での事例(wantedy)、docker remote API(https://github.com/fsouza/go-dockerclient)からdockerにアクセスする話、クレデンシャル情報をdocker環境で使う方法(外出しするのがベスト)、dockerでQA環境を構築した話(https://prevs.io/ja.html)、docker Hosting 「tutum」がありました。

共通でいえることは、dockerを使って耐障害性の高いシステムを構築するには、コンテナスケジューリング、監視がポイント。Kubernetes、ECSなどのコンテナ管理サービスは役に立つと思われる。DockerFileはシンプルに。DockerFileが複雑になるアプリケーションは、dockerには向いていない。(1 Process程度がいいとのこと)

コンテナ(docker)のユースケースとしては、Dev & Test、Auto deployment、Microservices、Batch Processing、社内PaaSがある。

以下については、別途順次検証等レポートしていきたい。

CoreOS

CentOS Atomic Host

Kubernetes

ECS

 

2015年1月14日
から hiruta
0件のコメント

Route53 Request Limitに対応するにはリトライは必須

通常のRoute53登録では問題になることはないが、Route53をVPCからしかアクセスできないPrivate DNSとして使えるようになったのは既知の事実。

Route53 Requestには、5 request/1s (AWSアカウント単位)の制限がある。AutoScalingでRoute53でリクエストする場合は、リトライ処理は必須となる。100%再現までとはいかないが、かなりの確率でAPI Errorが起きます。

AutoScaling Launch Configrationで使うことができるcloud-initスクリプトはqiitaにアップしてありますので、こちらを参照ください。

http://qiita.com/web_se/items/754353b49013a37913e5

2014年12月23日
から hiruta
0件のコメント

Lambda Meetup #0に参加してみて #LambdaMeetup

昨日ADSJで行われたLambda Meetup #0に参加しました。Lambdaの使用例からLambdaではまったポイントなど内容が盛り沢山でした。

[slideshare id=42949148&doc=zenza-lambda-141222191631-conversion-gate02]

Lambdaを使う上で、デモが動かない(アプリケーションサーバーからエラー)話。LambaのLimitを超えていた。3rdサービス(顔認識)とLambdaの間で処理がループしていて、LambdaのLimitを超えていたとのこと。LambdaのLimitについては下記。 http://docs.aws.amazon.com/lambda/latest/dg/limits.html

  • ADSJ 清水崇之 「LambdaとKinesisで作るど根性Tシャツ」

http://qiita.com/shimy@github/items/efa6cdf0955a110d8372

raspberry piからKinesis+Lambdaの事例。IoT(Internet Of Thing)は今後さらに広がっていくと予想されるので、Lambdaの用途も広がると思われる。

Lamdaは、エラー処理がポイント。LambdaはKinesis Stream、DynamoDB Streamと連携する際、Streamにゴミデータが入った、エラー取りこぼし処理がポイント。

  • 株式会社ディー・エヌ・エー 篠崎祐輔氏 「AWS Lambdaを紐解いてみた」

non-EC2によるフルマネージドの利点。見積、サイジングの削減が計れる。RDS、CodeDeployなどCIからデータベースまでフルマネージドのサービスが揃いつつあります。Lambdaはすべてがフルマネージドの出発点!

  • アンダースコア株式会社 諏訪悠紀氏 「Lambda × Mobileの可能性」

[slideshare id=42931562&doc=20141222lambdameetuplambdaxmobile-141222055859-conversion-gate02]

AWS SDK for iOSを自力でLambdaに対応してみた話。

Lambdaは、DynamoDB Stream、Kinesis Stream、S3イベント通知に対応しているが、現状SNS通知には対応してない。SNS通知が正式版ではほしい!Lamadaでは、定期実行がないので、バッチ処理ができない。

  • NRIネットコム株式会社 佐々木拓郎氏 「Lambdaで作るクローラー/スクレイピング」

[slideshare id=42966283&doc=awslambdameetup0-141223085825-conversion-gate01]

Lambdaに負荷をかけて、処理サーバーの負荷分散が行われる話。100リクエスト程度なら、同一サーバーで行われるが、1000リクエストとかかけるとサーバーも分散(自動スケールアウト)する。自動スケールアウトはフルマネージドの1利点。

  • クックパッド株式会社 菅原元気氏 「Lambdaによるクラウド型言語の実装」

[slideshare id=42933911&doc=20141222clala-141222074131-conversion-gate01]

すべての話で共通していたのは、フルマネージドサービスは極力使うのがサイジング、設計、運用でトータルコストを削減できる。

やはり、SNS通知のLambda対応、タイムアウト時間のカスタマイズ対応が待たれる。

 

2014年12月21日
から hiruta
0件のコメント

Ruuning InstanceをAutoScaling Groupに追加する機能について

Running中のインスタンスを簡単にAutoScaling Groupに追加できるメールがありました。

It is now even easier to get started with Auto Scaling for your Amazon EC2 instances. Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define. You can use Auto Scaling to help ensure that you are running the number of Amazon EC2 instances you need. Auto Scaling can also automatically increase the number of instances during demand spikes to maintain performance and decrease capacity during lulls to help reduce costs.
Starting today, we’ve made it easy for you to enable Auto Scaling on a running instance directly from the Instances view in the AWS Management Console. To learn how to enable Auto Scaling on running instances, please visit Attach EC2 Instances to Your Auto Scaling Group.

が、外部EBSを付け、ミドルウェアをインストールしたインスタンスをAutoScaling Groupにアタッチしてみました。

Launch Configuration、AutoScaling Groupはちゃんと作成はできました。が、実際インスタンスをterminateさせ、AutoScalingを発動してみました。

新たなインスタンスがLaunchはしてきましたが、外部EBS、ミドルとも元の状態には戻りませんでした。ミドルウェアを組み込んだAMIによるAutoScalingが結局必須の結論に。

2014年12月20日
から hiruta
0件のコメント

nginxのアクセスログをGoogle BigQueryに送信してみました。 #gcpja

GCP Advent Calendar 12/20のエントリ記事になります。LB + Autoscalerを書こうとしましたが、詳細に解説しているページがありましたので、HPCの基盤技術としてつけるBigQueryについて書きます。LB+AutoScalerについては以下で詳細にか書かれています。

http://qiita.com/soundTricker/items/951a02266a5c95165863

nginxのアクセスログの出力項目を変更します。time、hostがBigQueryのスキーマの項目に一致します。

     log_format  ltsv  'time:$time_iso8601\t'
                        'host:$remote_addr\t'
                        'uri:$request_uri\t'
                        'method:$request_method\t'
                        'forwardfor:$http_x_forwarded_for\t'
                        'request:$request\t'
                        'status:$status\t'
                        'size:$body_bytes_sent\t'
                        'referer:$http_referer\t'
                       'ua:$http_user_agent\t'
                        'reqtime:$request_time\t'
                       'upsttime:$upstream_response_time\t'

APIと認証→認証情報から、新しいクライアントIDを作成します。*.p12用のパスフレーズも表示されますので、控えておきます。下記作業では使用しませんが。

画像2

作成後、*.p12ファイルが作成されますので、サーバーの/etc/td-agentにアップロードします。

Fluentd pluginを導入します。

/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-bigquery
/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-forest

BigQuery用スキーマファイルを作成します。

[
  { "name": "time",    "type": "timestamp" },
  { "name": "size",  "type": "integer"  },
  { "name": "reqsize",    "type": "integer"  },
  { "name": "status",    "type": "integer"  },
  { "name": "host",  "type": "string"  },
  { "name": "uri",    "type": "string"  },
  { "name": "method",    "type": "string" },
  { "name": "ua",    "type": "string" },
  { "name": "vhost", "type": "string" },
  { "name": "reqtime",   "type": "float" },
  { "name": "apptime",  "type": "float"}
]

作成したスキーマファイルを使って、スキーマを作成します。

bq mk -t project_id:nginx_datasheet.access_log schema.json

S3にログを転送しつつ、BigQueryに送信するために、fluent-plugin-forestプラグインを使っています。

  type tail
  path /var/log/nginx/totalsolution.biz.access.log
  format ltsv
  time_key time_local
  time_format %d/%b/%Y:%T %z
  pos_file /var/tmp/nginx_access_log.pos
  tag nginx.access

# Output

  type forest
  subtype copy

      type s3

      s3_bucket XXXXXXXXXXXXXXXXXXX
      s3_region ap-northeast-1
      s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
      path logs/
      buffer_path /var/log/fluent/

     time_slice_format %Y/%m/%d/
     flush_interval 10m
     utc

      type bigquery
      method insert

      auth_method private_key
      email XXXXXXXXXXXXXXXX@developer.gserviceacco
unt.com
      private_key_path /etc/td-agent/my-cloud-environment-879d7473d230.p12

      project skillful-fx-531
      dataset nginx_datasheet
      table access_log
      buffer_chunk_records_limit 500
      buffer_chunk_limit 1000000
      buffer_queue_limit           5000
      flush_interval               1
      try_flush_interval           0.05
      num_threads                  4
      queued_chunk_flush_interval  0.01
      time_format %s
      time_field time
      schema_path /etc/td-agent/schema.json

画像3

 

Google BigQuery 機能 Redshift
95円/月
Wikipedia3億行
価格 \90,000
ストリーミング  不可
 Tableau  BI  Tableau

価格的にGoogle BigQueryが優位な結果に。

時たま500エラーがでるようだが。

 tabledata.insertAll API project_id="skillful-fx-531" dataset="nginx_datasheet" table="access_log" code=500 message="Unexpected. Please try again."
 [warn]: retry succeeded. instance=70122832844240

確かに、サーバーエラー(500)が起きている。考えられることはBigQueryのLimit、ネットワークがあるが。

screencapture-console-developers-google-com-project-skillful-fx-531-apiui-apiview-bigquery

2014年12月19日
から hiruta
0件のコメント

EC2 Container Serviceファーストインプレッション #jawsug

EC2 Container Service (ECS)のプレビューが通りましたので、早速Getting Started通りではありますが、試してみました。 プレビュー用のAWS CLIをまずインストール。AWS CLIは、1.6.5のようです。

$  aws --version
aws-cli/1.6.5 Python/2.7.5 Linux/3.10.0-123.el7.x86_64

Clusterをまず作成。もちろんap-northeast-1ではエラー。

$  aws ecs create-cluster --cluster-name MyCluster --region ap-northeast-1

HTTPSConnectionPool(host='ecs.ap-northeast-1.amazonaws.com', port=443): Max retries exceeded with url: / (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

us-east-1で無事ACTIVEに。

$  aws ecs create-cluster --cluster-name MyCluster --region us-east-1
{
    "cluster": {
        "clusterName": "MyCluster",
        "status": "ACTIVE",
        "clusterArn": "arn:aws:ecs:us-east-1:XXXXXXXXXXX:cluster/MyCluster"
    }
}

CommunityAMI ami-34ddbe5cを使って、ECS用に最適化したインスタンスをLaunchします。 cloud-initに以下を入力

#!/bin/bash
echo ECS_CLUSTER=MyCluster >> /etc/ecs/ecs.config

root volume は、30GBがデフォルトで設定されています。

aws ecs list-container-instances --cluster MyCluster --region us-east-1
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:XXXXXXXXXXXXXX:container-instance/be81fda7-5486-4584-89d0-2f8bff6119d3"
    ]
}

これですが、インスタンスタイプにt2.microを使ったためかもしれませんが、はじめMISSINGでしたが、無事ACTIVEに。

aws ecs describe-container-instances --cluster MyCluster --container-instances be81fda7-5486-4584-89d0-2f8bff6119d3 --region us-east-1
{
    "failures": [],
    "containerInstances": [
        {
            "status": "ACTIVE",
            "registeredResources": [
                {
                    "integerValue": 1024,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "CPU",
                    "doubleValue": 0.0
                },
                {
                    "integerValue": 996,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "MEMORY",
                    "doubleValue": 0.0
                },
                {
                    "name": "PORTS",
                    "longValue": 0,
                    "doubleValue": 0.0,
                    "stringSetValue": [
                        "2376",
                        "22",
                        "51678",
                        "2375"
                    ],
                    "type": "STRINGSET",
                    "integerValue": 0
                }
            ],
            "ec2InstanceId": "i-0000000000",
            "agentConnected": true,
            "containerInstanceArn": "arn:aws:ecs:us-east-1:XXXXXXXXXXX:container-instance/be81fda7-5486-4584-89d0-2f8bff6119d3",
            "remainingResources": [
                {
                    "integerValue": 1024,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "CPU",
                    "doubleValue": 0.0
                },
                {
                    "integerValue": 996,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "MEMORY",
                    "doubleValue": 0.0
                },
                {
                    "name": "PORTS",
                    "longValue": 0,
                    "doubleValue": 0.0,
                    "stringSetValue": [
                        "2376",
                        "22",
                        "51678",
                        "2375"
                    ],
                    "type": "STRINGSET",
                    "integerValue": 0
                }
            ]
        }
    ]
}

ECS用インスタンスの中身を確認しました。

$ which docker
/usr/bin/docker
$ docker ps
CONTAINER ID        IMAGE                            COMMAND             CREATED             STATUS              PORTS                        NAMES
844d5e0fe2fd        amazon/amazon-ecs-agent:latest   "/agent"            6 minutes ago       Up 6 minutes        127.0.0.1:51678->51678/tcp   ecs-agent

dockerのバージョンは、1.3.3

$ docker -v
Docker version 1.3.3, build c78088f/1.3.3

後ほどいろいろ検証してみたいと思います。

※Preview通っていないアカウントでは、もちろん利用できません。

$  /home/hiruta/.local/lib/aws/bin/aws ecs create-cluster --cluster-name MyCluster --region us-east-1

A client error (OptInRequired) occurred when calling the CreateCluster operation: The AWS Access Key Id needs a subscription for the service