クラウドインフラ構築記

Amazon Auroraに引き続き、CloudSQLのベンチマークを測定してみました。Cloud SQLに、Amazon Aurora相当のインスタンスタイプがないので、厳密な比較はできませんが、参考程度に。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

CloudSQLは以下の状態で行いました。

メモリ4G※CPU情報については公開されていませんので、コア数は不明。mysqlのバージョンもmysqlに接続して確認。gcloudとDeveloper Consoleから確認はできない。

測定用インスタンスは、CloudSQLと同じリージョンにあるpreemptible VM (n1-standard-1)で。

検証用とかにPreeemtible VMお得で便利です。

結果

Cloud SQLは、IPv6にも対応、Repliaなどにも対応しているので、今後期待できるサービスです。

Cloud SQLはGCEのネットワークに配置することができないので、今後改善してほしいところ。

Amazon Auroraのベンチマークを測定してみました。

ベンチマーク環境

ベンチマークの種類

RDBMSのベンチマークで一般的なTPCのオンライントランザクション処理の指標である「TPC-C」を行います。
ベンチマーク用ツールはMySQLのOracle ACEである平塚氏が作成したJdbcRunnerのTPC-C簡易実装であるTiny TPC-Cを使用します。

使用データ

RDSは以下の状態で行いました。

RDSと測定用クライアント(r3.xlarge)は別AZに配置。

結果

まとめ

多重度1でquery_cache_typeを変更して測定してみましたが、on/offの差は見られませんでした。

また、RDSと測定用クライアントを同一AZに配置した場合に比べて、3割程度の性能劣化が見られました。

以下は、測定用クライアントとRDSが同一AZにあった場合の結果になります。

7/25 産業技術大学院大学で行われた　July Tech Festa 2015に行ってきました。

以下のセッションに参加しました。

IoT時代のデバイスクラスタHashicorp consulを用いたIntel Edisonクラスタの構成

fogとクラウドどう役割分担させるのがポイント。fogはリアルタイムの処理を行い、クラウド側では大量データ蓄積、分析・学習に利用する。

実際構築したシステムの技術の解説。MQTT、Wi-Fi Mesh Network、Consul

MQTTは、TLSで暗号化が推奨。

Wi-Fi Mesh Networkは、SPOFにならないとか良い点もあるが、デフォルトカーネルでは動かず、カーネルビルドが要。→

Consul 運用自動化ツール。Wi-Fi  Mesh Networkと相性が良い。Go 1.4 x86 32bitのバイナリで動かせる。

真剣にDocker運用を考える人に、各種監視ツールとサービスを比

Dockerの監視を自作(DIY)で、それとも、SaaSの監視サービスでまかないか。

Docker  Containerの監視粒度は、1回/5分では不十分。1データ/1秒、一年間保存位しないとNG

CloudWatchの監視粒度とかではDocker Containers監視は不十分ということに。

Docker Containers監視を自作(DIY)で求められる監視粒度が満足できればいいが、そうは簡単ではない。

SaaS系の監視サービスだと、サービス終了した場合はどうするか個人的には気になる。

New Relic、App Dynamics、Mackerel、Signakfx、libratoについて、一丁一端がある。

DatadogがDocker Containers監視については現状ベストとのことに。

今話題のAnsibleのモジュールをゼロから自分で作ってみよう

標準で提供されているモジュールだけでも十分だが、かゆいところまでしたい場合はモジュールを作成する。

本当に足りない機能をモジュールで作成するのがいい。(今回のセッションではSolarisのホスト名変更が標準では対応していないので、モジュールを書いて、pull requestした話がありました。）

開発したモジュールを標準モジュールに取り組んでもらうには、いくつかのルールがある。説明、利用例に準拠させる必要がります。

仮想化とストレージの新しい形！ハイパーコンバージインフラの技術解説

オンプレのストレージ仮想化は、スモールスタートしずらい

安価なストレージ仮想化では、SANのポート、ストレージヘッドの性能に制限

拡張する場合、非効率なサイロ化

そこで、ソフトウェア処理で何とかするのが、Nutanix

Googleが描く、MapReduceを超えたビックデータの世界

Googleのコンテナ技術Borg

Google BigQuery

Googleも初期には、oracleとかRDBを使っていたが、膨大なGooogle検索のインデックスを管理するPBサイズになり、対応しきれなくなったとのこと。BigQueryのサービスが生まれた。インフラをあまりしらないユーザも使える。最適化されていたクエリ（糞クエリ）も高速で実行が可能。管理者不要、パフォーマンス劣化がない

1,000億行Read(フルスキャン)しても、20秒かからない。

RDBだと、一台のマシンで1日かかることも。

BigQueryがなぜ速いのかの説明。カラム指向ストレージ。カラム毎に異なるストレージに入れるので、クエリ実行効率、圧縮効率もいい

数千台のサーバーで並列実行。他のクラウドだとマネできない。

RasPiからBigQueryにも。fluent-plugin-bigqueryを使う場合、GCEだと、AWSでいうIAM Roleに相当する自動でアクセスするcredentailsを取得する仕組みがRasPiとかIoT deviceだと使えないのが課題。

Google Dataflow

機械学習（Machine Learning）

実行環境側でshared。Kinesisの場合、sharedをKinesis Streamを作成する際、指定する必要があるが、スケールも自動でしてくれる。

Amazon Linuxのdocker imageを作成し、Google Container Registryにアップロードを行い、

Amazon Linuxのdocker イメージを作成する方法については、http://dev.classmethod.jp/cloud/aws/docker-serverspec-configspec-ci/　を参照にしました。

AmazonLinux dockerイメージをローカルのdocker環境にインポートします。

# docker import < amazonssh.tar

# docker tag amazonssh asia.gcr.io/#your-project-id#/amazonssh

Google Container Registryにアップロードを行います。

# gcloud docker push asia.gcr.io/#your-project-id#/amazonssh
The push refers to a repository [asia.gcr.io/#your-project-id#/amazonssh] (len: 1)
Sending image list
Pushing repository asia.gcr.io/#your-project-id#/amazonssh (1 tags)

適当なVMインスタンスを起動します。GCSへのリード書き込み権限を付与することを忘れずに。

# gcloud compute instances create instance-test-docker --image centos-7  --scopes https://www.googleapis.com/auth/devstorage.read_write

dockerのインストール、起動

# yum install docker

# service docker start

asia リージョンのバケットにアップしたので、gcr.ioで見つからないとエラーとなります。

# docker pull gcr.io/your-project-id/amazonssh
Trying to pull repository gcr.io/your-project-id/amazonssh ... not found
FATA[0000] Error: image your-project-id/amazonssh:latest not found

Google Container Registryからdocker イメージを取得します。

# docker pull asia.gcr.io/your-project-id/amazonssh
Trying to pull repository asia.gcr.io/your-project-id/amazonssh ...
3fe81e712d9e: Download complete
a09fe07f3274: Download complete
81bcdeaea41c: Download complete
7ad48843769c: Download complete
9b15589bc305: Download complete
48fc49b0c3fa: Download complete
25a9a1b3f0d0: Download complete
cbfa77630235: Download complete
76ab5065c4b2: Download complete
Status: Downloaded newer image for asia.gcr.io/your-project-idamazonssh:lat

docker イメージがpullできていることを確認できます。

# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
asia.gcr.io/your-project-id/amazonssh latest 3fe81e712d9e 2 weeks ago 874.1 MB

docker containerを起動

# docker run -h amazonssh -t 3fe81e712d9e /bin/bash
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5534906edb50 3fe81e712d9e:latest "/bin/bash" 17 seconds ago Up 16 seconds 22/tcp agitated_fermi

GCEでAmazon Linuxの環境を構築することも可能となります。

Container-Optimized Compute Engine Instancesでインスタンス起動時にContainer Registryから取得して、Containerを起動することも可能ですが、こちらについては、別途機会に。

Elastic File SystemのFeedback（バックアップについて）を送ったら、下記回答が得られました。

We do not currently have a “snapshots” feature, but you can use standard file system tools and practices such as performing an rsync to another file system, running a script to take regular rsync-based differential backups, creating ad-hoc copies of individual directories, using third party backup tools, etc. to protect your data against logical corruption.

EFSは、snapshotsは対応していないとのこと。rsyncのような標準のシステムツールでバックアップするてことになる模様。サードパティ用のバックアップを併用するのがいいようです。

ある時間から復元するようなことはできない。バックアップの設計は別途必要か。

6/18 (木）に、六本木ヒルズ（アカデミーヒルズ49F)で行われた GCP Next Tokyoに参加してきました。GCP Nextはニューヨーク、サンフランシスコ、東京、ロンドン、アムステルダムで開催される世界規模のGCPのイベントになります。

GCP Next自体何年か前から開催されていましたが、当初は、40名程度でしたが、今年は、キーノート会場は満席、立ち見もある盛況ぶりでした。

HTC様のGCPを使った事例

デバイスの同期
デバイスの更新周期3年
デバイスを超えてアプリケーションを実行
少ない帯域でアプリケーションに対応
DCのレプリケーション
距離的に近いDCを選択
接続障害に対する耐性
アプリケーションは切断しても続行

上記課題に対して、GCPを使うことでどう解決したかの話

バージョンコントロール
push通知クライアント同期
差分だけを転送する

Googleの技術サポートはエンジニアが対応するので、きめ細かな対応も評価しているとのこと

pwc

消費型モデルをどう構築するか

GCPを選択した理由
分析の部分
重要な部分を担っている。セキュア、全体のトレンド
世界中にスケールするインフラが必要
今プランを策定しないと間に合わない

クラウドプラントフォーム一連のサービスがまとまっているもの

70 エッジローケーション
33カ国

レイテンシーの信頼性の高いネットワーク
500人のセキュリティエクスパート
ミッションインポッシブルの技術レーダーによる侵入検知
データを傍受して読むのも不可能

Broadleaf

なぜGoogleをインフラとして選択したか

当初は、自社のDCを構築
40,000万社を接続してコントロール
ネットワークで卸、工場を接続

AWSも検討したが、GCP上での動作実績のあるMEGALLANのミドルウェアがあるため、GCPを採用

Gooogleの方が拡張性に優れている、大量トランザクションに耐えうる。

こちらでも、サポートが優れている。通常では対応してくれないこともしてくれる

GCP移行後は、システム停止も発生していないとのこと（ライブマイグレーションなどメンテナンス不要にする機能も使えます。）

Groovenauts

最も速く、最も協力で最も質の高いクラウドプラットフォームで構築してきました。
くみ上げていく運用する時代の終焉
新しいビジネスに集中もできる。

クラウドは、やめるのも、使い続けるのも可能。新しいイノベーションも生まれやすい。

ここまでの午前中の部（キーノート）

午後は、ビジネストラック、デベロッパートラックに分かれてセッションがランチを挟んで続きました。

両者のうち、ビジネストラックを選択しました。

Engine入門

AppEngineは、PaaSの名もまだの時代に生まれたサービス。

Container Engineは、VMの依存性を解決するが、コンテナ間通信、セットアップ、ホスト間移動の課題を解決するために生まれた。

Compute Engine、i2.xlargeとn1-highmem-4を比較して、GCPのコストパフォーマンスの良さが話された。

Fastlyでは、リバースプロキシVamishを使って、4万リクエストを裁いてしまう。

Compute Engine自体インスタンス起動も秒単位。(AWSだと数分かかる)

クラウドネットワーキング

長年15年投資してきた。光ファイバー
GCPは新しいけど、インフラは長年やってきました。

SDN
どこでもベストパフォーマンスが得られる

Direct Peering

PGP Peering

Private network 相互接続
公共インターネットを経由しない
パフォーマンスも予測しやすい
揺らぎに依存もしない

Carrier Interconnect

Service Providerを介してPeeringなしで接続

Equinix

Equinix Performace Hub

ISP, NSP
自分のキャビネットから
往復の遅延は低い
セキュリティ、コンプライアンスも維持

ビックデータ

データの世界がチェンジ
量が爆発的に増加 ログファイル、エンドポイント、デバイス
アーカイブも
データが10倍に

320億のIoTデバイス
リアルタイムでキャプチャしないといけない
クラウドベースのコンピューティング

ビックデータは複雑

Google NoSQLの導入したけど

Map Reduceでリーズナブルに分析ができない
コンピューティングリソースも必要
チャンスもあるけど、活用できない問題も
より使いやすくする

70%はインフラ構築等などに時間を費やしている

データをコンバージョンするときに時間を使えるようにする

経年劣化
速く使えばデータの可視も

SUNGARD、DeNAの事例について。

Tableau

当初はデータの可視化を目指す
自分でデータを見て、理解することを手助けるのがTableauの会社創立の使命とのこと
だれでも簡単にデータを分析することを目指す。

数字は瞬時に理解することはできない
グラフにして初めて理解できる。

Tableau Onlineは、Tableau Desktop、Tableau ServerのようにChorme、Safari等ブラウザ以外一切ソフト導入が必要としない。分析とかも問題なく利用可能。

年間サブスクリプション価格が、破格の60,000円。（支払いは年間一括。月額は現状ないが、検討してもらいたい）

Tableauは、CloudSQLに接続することも可能。※credentialsには気をつける。tableauのデモの際にも、BigQueryに接続できないことがあった。

管理（Cloud Monitoring + Logging )

70%はメンテナンスの維持に使われている
イノベーションしたいとしても10%以下の現実

Cloud Monitoringはメンテナンスの手助けをしてくれる。

AWSでできないことも、GCPだと解決できることもあることがより実感できるイベントでした。

昨年末のre:Inventで発表されたAmazon Auroraが八ヶ月ほどでようやく使用できるようになりました。

provison 3 (リリースバージョン？）が使用できるようになりましたので、Amazon AuroraをManagement ConsoleからLaunchしてみました。

使えるようになったAuroraのバージョンでは、preview専用画面ではなく、他のRDSエンジンと統合されています。

対応インスタンスは、db.r3.largeとdb.r3.xlargeのみ。（これしか選択できない）

現在のRDS ( MySQL )とは、Multi-AZの概念が少し異なっています。Master & Replica で構成されます。現在では、Read Replicaは別途Launchするが、Auroraは、Multi-AZで、Crearte Region in Different Zoneを指定すると、初期構築時に作成されます。

Provisoned IOPS、gp2かディスクストレージは明示的に設定できないようです。また、マイナーバージョンの指定がなくなっており、シンプルになっています。

初回時バックアップの時間指定がない。バックアップ時間は、04:05 – 04:34で登録されるようです。

Multi-AZ構成にすると、Master/ReadReplicaが明示的に表示されます。Master 2Zone、ReadReplica 2Zoneを使用するようにみえる。3AZ（1 AWSアカウントでは事実上2AZしか使えない）しかない東京リージョン対応の際、どのようになるのか。

FailoverがRebootとは別に項目が追加されています。

RDS Event SubscriptionももちろんAuroraでも対応しています。Event Subscriptionのカテゴリは別段変わっていない模様。

AWS CLIからはまだ未対応ですので、作成はManagement Consoleのみとなっています。

細かい点はのちほど。