クラウドインフラ構築記

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

2015年3月30日
から hiruta
第11回クラウドごった煮参加レポート #cloudmix はコメントを受け付けていません

第11回クラウドごった煮参加レポート #cloudmix

3/28 産業技術大学院大学で開催されたクラウドごった煮勉強会参加レポートになります。

コンテナ技術は、GKEをはじめとするコンテナ管理ツールが充実、OSレベルでもRHEL Atomic Host、CoreOSと選択肢はできてきた印象。開発環境だけでなく、production環境にも採用してきている一番盛り上がっている技術でもある。

IBM Containers

IBMとDocker社と戦略的パートナーとして提携

IBM Bluemix(PaaS)上で提供されている。

SoftLayer上にPaaSを実装

Bluemix = Cloud FoundryベースのPaaS

Dockerの実行環境とプライベートリポジトリを公開している

Bluemix のホストは、SoftLayerのベアメタルサーバー上で動作している

iceがcf(CloudfoundryのCLIツール)とか隠蔽しているとのこと

 

RHEL Atomic Host

/varだけ書き換えられる。監視ツールを入れたい場合は、コンテナに。

Kubernetes and Google Containers Engine (GKE)

Pods 密結合したコンテナの集まり。

yaml に、いくつ起動するか記載して、コンテナが落ちた際に起動する

特定のIPアドレスを持たせる

数ヶ月のうちに、Versionは、1.0となるとのこと。

数十Podsを扱えるようになる。

Private リポジトリをCloud Storageに作成できる

DockerHubのプライベートリポジトリは参照できない模様。

AmazonLinux Docker Imageを、GCE上のdocker実行環境でrunするところまでは確認しましたので、GKEを使って上げ下げをトライ中。詳細は別記事にて記載します。

Docker Machine

Apache Mesos

クラスタ環境の管理ツール

10,000スケール程度まで可

ヘッドノードを可用性で ZooKeeper

実行環境をジョブごとに変えられる

Mesos DNS

IPがわかっても、ポートがわからないと ポート番号が分からないとアクセスできない

Rancher.ioを試してみる

[slideshare id=46435599&doc=rancher-150330021249-conversion-gate01]

クラスタを管理するシステム
Docker版Opn Stackのようなイメージ
リソースの監視もできる。

Docker run -p 8080:8080 rancher/server
ホストの追加はWEB UIで
導入は楽。コンテナが動けば動いてしまう。
コンテナで括っているので、拡張性がない
今はセキュリティグループはない。今後実装予定
https://github.com/stevef1uk/docker_for_rpi

Monitoring Docker with Mackerel

コンテナの監視もMackerelで。

Cgroup特有の情報は見えない
/sys/fs/cgroup/{cpuacct,memory}
リソース制御するのもこの辺をいじる
/sys/fs/cgroup/cpuacct/docker/{container id}/cpuacct.usage

メモリはcacheとかも
memory.stat

また、Radpberry Piでもmarchel agentは動く。

[slideshare id=46435598&doc=rpi-150330021248-conversion-gate01]

2015年3月27日
から hiruta
第二回Intel Edison 勉強会に初めて参加してみて #IntelEdisonUG はコメントを受け付けていません

第二回Intel Edison 勉強会に初めて参加してみて #IntelEdisonUG

今日Intel Edison 勉強会が、歌舞伎座タワー19F ドワンゴ様のセミナールームでありました。JAWS DAYSでHack Daysでハンズオンを受講しましたが、IoTに注視(IoTのインフラ基盤も)しています。

OSアップデート

OSアップデートは、Reboot otaではなく、flashall.batの方が。flashall.batだと設定がすべて初期化されます。Edisonが起動できなくなった場合にもflashall.batで復旧ができる。

Wi-Fiダイレクト(Edison同士をつなぐことができる。アドホックネットワークを構築できる?)や、パーティション割り当ての変更等、バグフィックスも多数。

後述の発表でもあるIoTで最適プロトコルと行っていいMQTTがはじめから使える(mosquitto、root権限で実行するとのことですが)

Edison を色々試してみた

[slideshare id=46309857&doc=edison-150326051335-conversion-gate01]

Edisonを組み込んだ(組み立てた)製品の紹介。

MQTTというTCP上で動くプロトコルについて

[slideshare id=46312662&doc=edison-mqtt-2015-03-26-150326063723-conversion-gate01]

IoTは、細切れのパケットを送受信するので、最適。シンガポールのDCに飛ばして、シンガポールのDCから送信するデモでしたが、距離を意識しないレイテンシでした。(WICEDを使ったデモ)

MQTT as Service sango という MQTTのManaged Serviceの紹介話も。 sangoのインフラ基盤はDigital Occeanとのこと。IoT通信の場合、かなりの数のIoTデバイスがサーバーにアクセスすることも考えられるので、データ転送量の考慮も必要。

MQTT通信スクリプトが書ける MQTTCLI (https://github.com/shirou/mqttcli)もあるが、本セッションでnode.jsを使ったMQTT通信の話。

Edison v.s Raspherry Pi徹底比較

Edisonは軽量。消費電力が低い。インターフェースにWi-Fi Dual band(2.4G/5G)、Bluetoothがあり、Raspherry PiがEthernetのみに比べて、優位。ストレージは、SDカードが使えるRaspherry Piには劣りますが。Raspherry PiがPCに近い位置づけと考慮すると納得。

AtomのCPUでDual Core。32bit OSですが、64bitを疑似ですが、問題なく演算ができる。

2015年3月23日
から hiruta
JAWS DAYS 2015に参加しました。 #jawsug #jawsdays はコメントを受け付けていません

JAWS DAYS 2015に参加しました。 #jawsug #jawsdays

昨日開催されたベルサイド新宿グラウンドで開催されたJAWS-UG 1年に1度のビックイベント「JAWS DAYS 2015」に参加しました。JAWS-UG歴も振り返ってみました。

[Aceに聞け] cloudtrailとconfigによるセキュリティ強化のための第一歩

1

 

はじめてのIoT 〜 IoTデバイスとクラウドの素敵な関係 〜

IoTデバイスとクラウドを使ってセンサーハック 〜 データ可視化 〜

2

 

午前の部は、Edisonにサンプルのnode.jsをアップロード、ビルド、実行し、LEDセンサーが点灯するサンプル等を試しました。(1xGrove – Rotary Angle Sensorのトグルがoffになっていると点灯もされません。)

 

午後の部は、Kinesis、Cognitoを使って、Edisonのセンサーから取得されたデータをグラフ化+S3にデータをアップロード/DynamoDBへのデータ挿入までハンズオン形式で行いました。

グラフ化とS3アップするKinesisアプリケーションを動かすEC2は分けるとグラフ化とデータ蓄積をマルチで行えます。午後Part 1のセッションでは、EC2 x1でしたので、ハンズオンでは、ここまでは確認はしませんでした。

Edisonを始めたい方は、Grove – Starter Kit for Arduinoも一緒に購入するのがお勧め。(今日購入しました。)

“モノ”をクラウドへつなぎやすくするための取組/技術/アーキテクチャ

IoT動向、海外イベントの話から、IoTアーキテクチャー

3

IoTは95年時代のインターネットのブームに似ている。生活家電にIoTデバイスが組み込まれ、インターネットに接続される時代が近い将来くる。収集・蓄積・分析のトライアングルが重要

IoT時代のデータ伝送とインフラに求められている機能

4

IoTのクラウドからの反応速度は、1秒。かなりシビアな用件が求められる。IoTゲートウェアに機能を詰め込みすぎず、最低限の機能で実装するのが求められる。設置場所も簡単に交換するのが難しいところに設置されるケースもあるので。(MDFの中とか)

cloudtrail以外には、IoTを中心というか、IoT一色になっていました。

午前の部のHack DaysがトグルがOFFになっているため、LEDが付かない原因に至るまで時間がかかりました。

最もリツイートが多かったツイートは

IoTのネットワークは、「運用でカバー」で対応は難しいとのこと。ゲートウェイはシンプルに。(credeitalsキーをIoT deviceの中に入れるのは論外。Cognitoを使って、AWSサービスにアクセスする)

JAWS-UGの勉強会には、意外に一年半前に開催された

screencapture-jawsug-chiba-doorkeeper-jp-events-6891

 でした。

ビックのイベントとしては、DAYSの他には、JAWS-UG三都物語てところ。(re:Invent 2014に去年初めて参加しましたが)
AWSのアカウント自体は、6-7年前には作っていた記憶が。(EC2-Classicが使える、Default VPCが使える。AWS CLIのハンズオンでは。。。)

最近は、Google Could Platformのユーザグループ「GCPUG」にも参加していますなど、個人的には、GCE、GCE Auto Scaler、GKE、Google Dataflowなど検証しております。

4/11にはこちらにも →ここ (立ち見でいいのであれば今からでも申し込みできます) Google Dataflowの話とか、GCEハンズオンワークショップなどもかなり盛りだくさんの内容になります。

screencapture-gcpugfukuoka-connpass-com-event-13204

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対応、タイムアウト時間のカスタマイズ対応が待たれる。