GCP vs 他社クラウド

GCE vs 他社クラウド株式会社 Zeadle 長谷川祐介 2014-04-17

はじめに

•開発中のため予定のものが含まれています

• スーパーエンジニアってわけでもないので気楽に聞いて下さい！

index

• 会社説明

• 自己紹介

• ゲーム紹介（現在開発中

• アーキテクチャ（現在開発中

• GCE vs 他社クラウド

会社説明社名 株式会社Zeadle

設立 2013年

代表 川方慎介

社名の由来 Zeal(熱意)とDoodle(いたずら書きをする)

現在9名+1羽のメンバーで開発中！

自己紹介氏名 長谷川祐介

経歴20代にGMO, Yahoo, SQEXその他中小を転々としながら

2010年にgloops(旧gms)へ 2014年4月1日からZeadleへ

職種いわゆるインフラエンジニア

CIO（ちっちゃなインフラおじさん）

GCP歴 約2ヶ月

その他 AWSここ最近半年くらい AzureもVM側だけど数ヶ月触ってる

ゲーム紹介

現在開発中！

ゲームタイトル

グラフィックは

すべてKIRARITOさん！

もう一発

KIRARITO！

アーキテクチャ現在開発中なもんで内容が薄いですが！！

Google各種サービス

Compute Engine Application / WebSocket redis, MySQL etc…

CloudDNS 名前のとおり！

CloudStorage 静的ファイル配信 CDNもそのまま利用

BigQuery KPI関連

Google Analytics もはや説明の必要なし

お世話になるみなさん！

がんばって作ったので・・・

さっきのごちゃごちゃを 分解していきます

Application

WebSocket

Deploy（予定）

ApplicationのActive/StandbyをInstance内で行う！

Monitor• すべてのInstanceでZooKeeperClientを起動

• ZooKeeperへはEphemeralNodeでHostの情報を保存

• InfluxDBはCollectData

• 通知はHipChatを利用予定

Operation Central• デプロイとか

• オーケストレーションとか

• コンフィグレーションとか

• 基本管理系はここからやろうかなと

• MonitorのApache ZooKeeperにあるデータを利用する形で運用フローを検討中

KPI

• Google Analytics + BigQueryを活用予定！

• まだ何も決めていないのでこれから・・・

bootstrap

• 基本はsnapshotでやろうかなと検討中

• MiddlewareのInstallなどはprefix切ってbuildして入れたい（趣味）なのでbuildしたbinaryをそのままgitに・・・

• ansibleでgit pull？

AutoScale（検討中• まだ機能が公式にないので自作

• MonitorでとっているOSの監視データを元に行う（しきい値は多分いろいろ考慮するはめになると思う！

• ApplicationDeployは必ずgitのtagで行い、tagをZooKeeperに保存しておけばあとで利用できると考えてます。

• 上記を基にSnapshotからOSを起動Applicationはtagを元にgit pullしてからバランサーに追加する！

• なんか実際作るとなるとJobQueue欲しいなぁ・・・ｗ

GCE vs 他社クラウド

構築していく中で 気がついたことを！

GCEだけじゃないですが！

という流れで現在開発構築真っ最中なわけですが

いきなり結論ですが

第一に感じたこと 全体的に

非常にスッキリしている！

Compute Engine• 起動がちょっぱや！

• CPUも同等のEC2 Instance Typeと比較すると速い（よくbuildするので感覚値

• いわゆるregionがない

• USにInstance立てているのになんでか速い

• 通常のInstanceについているDiskも悪くない（buildしてるとわかる

Google塩入さんの受け売りです・・・

VMインスタンス• 起動は本当に速いだいたい1~2分くらい

• ディスク作成、スナップショット取得などは体感的にも高速（10GBのDiskのInstanceで2分程度

• タグはカンマ区切り

• Image管理はsnapshotでやった方が楽なんじゃないかと感じてます。どうなんでしょうか？

• 管理上作った日付が欲しい場合もあると思いますが gcutilであれば --format=json付きでgetinstance/listinstancesのcreationTimestampで取得できます。

ディスク• Diskサイズにより性能向上するらしい

• マウントを簡単にできるツールも付属してる！（こいつがかなり楽でいい！

$ sudo /usr/share/google/safe_format_and_mount -m "mkfs.ext4 -F" /dev/<disk-or-alias-name> <mount-point>

メタデータサーバー• alt=jsonでJSONで取得できる！（これマジで嬉しい！

• tagが取得できる！（これが便利！

• Project単位でインスタンス全体に反映するroleや特定インスタンスにだけ反映するカスタムメタデータがある！（個人的に応用範囲が広いんじゃないかと・・・

$ curl -H "X-Google-Metadata-Request: True" http://metetadata/v1/instance/network-interfaces/0/ip 10.240.31.180

負荷分散• ターゲットプールいわゆるバランサーメンバー対象のWebServerを複数指定

• 転送ルールバランサーのIP、プロトコル、ポート、ターゲットプール

• ヘルス チェックホスト、ポート、パス、間隔、タイムアウト異常とみなす基準、正常とみなす基準

• ヘルスチェック、ターゲットプール、転送ルールの順番で作成すれば作れます。

ヘルスチェック

• 名前を入力

• パスを入力

• 間隔、タイムアウト入力

• 異常とみなす基準、正常とみなす基準を入力

ターゲットプール

• 名前を入力

• 地域を選択

• VMインスタンスを選択

• ヘルスチェックを選択

転送ルール• 名前を入力

• 地域を選択

• 外部IPを選択

• プロトコルを選択

• ポート/範囲を選択

• ターゲットプールを選択

負荷分散

これだけでできあがり

LBへのインスタンスの追加・削除

gcutil --service_version="v1" \ --project="xxxxx-xxxxx-xxx" \ [addtargetpoolinstance|removetargetpoolinstance] \ --region="us-central1" \ --instances="test" \ test-targetpool

• 反映も数秒で完了するので非常に扱いやすい

hostname

• インスタンス作成で付けた名前がそのままhostnameになります。

• また同じProject内のインスタンスはシンプルに上記hostnameで名前解決できます。

• ここらへんは非常にスッキリしてていい感じ！

アカウント• ぶっちゃけ今回一番驚いたことです！

• Google AppsのアカウントとVM内ユーザーが連携！

• manage_accountsというプロセスが起動しており、 Developers Console上の権限に追加すると LinuxOSのユーザーが自動で作成されます。

• Developers Console上から権限剥奪すると ちゃんとLinuxOSにLoginできなくなります。

• Google Cloud Platformと名付けられている理由が！！！

構築上非常に便利な点！WebのDevelopers Console上で

RESTとコマンドラインが出力される！

gcutil --service_version="v1" --project="xxxxx-xxxxx-xxx" addinstance "test" --tags="test" --zone="us-central1-b" --machine_type="n1-

standard-1" --network="default" --external_ip_address="ephemeral" --service_account_scopes="https://www.googleapis.com/auth/

userinfo.email,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/devstorage.full_control" --image="https://www.googleapis.com/compute/v1/projects/centos-cloud/global/images/centos-6-v20140318" --persistent_boot_disk="true"

Cloud Storage• fluentdからLogを送るのはfluent-plugin-gstoreでできます。

• 静的ファイル配信はFileをUploadし公開flagを立てるだけでできます。

• あと権限周りが非常に面白くて、GoogleAppsのDomainだけ許可したりできます。

• gsutilでUpload(約100MB)したらすごい遅かった・・・ けど-mオプションつけたら気にならないくらい速い！ 約100MBが2分くらいでUpload完了

• これからDeployTool作るんですがcomposeが便利そう

Alternate-Protocolが気になる！

CloudDNS

• updateを行う

$ gcloud components update dns

$ gcloud dns managed-zone create --dns_name="zeadle.org." --description="zeadle org” zeadleorgzone

• managed-zone create

• 2014-04-15現在はまだDeveloper Consoleは提供されてないのでCLIでやりました。

CloudDNS

• edit

$ gcloud dns records --zone=zeadleorgzone edit

CloudDNS{ "additions": [ { "kind": "dns#resourceRecordSet", "name": "zeadle.org.", "rrdatas": [ "ns-cloud-b1.googledomains.com. dns-admin.google.com. 2 21600 3600 1209600 300" ], "ttl": 21600, "type": "SOA" }, { ここに入力 } ], "deletions": [ { "kind": "dns#resourceRecordSet", "name": "zeadle.org.", "rrdatas": [ "ns-cloud-b1.googledomains.com. dns-admin.google.com. 1 21600 3600 1209600 300" ], "ttl": 21600, "type": "SOA" } ] }

• viが立ち上がってきて（ちっちゃくてすいません・・・

CloudDNS

{ "kind": "dns#resourceRecordSet", "name": “www.zeadle.org.", "rrdatas": [ “xxx.xxx.xxx.xxx”（ここにglobal-ipを） ], "ttl": 21600(ここはお望みのTTLを), "type": "A"（CNAMEとかもできました！） }

• 入力するデータ

• viで保存すると反映します！

CloudDNS

$ gcloud dns records --zone=zeadleorgzone list

• 確認

CloudDNS[ { "kind": "dns#resourceRecordSet", "name": "zeadle.org.", "rrdatas": [ "ns-cloud-b1.googledomains.com.", "ns-cloud-b2.googledomains.com.", "ns-cloud-b3.googledomains.com.", "ns-cloud-b4.googledomains.com." ], "ttl": 21600, "type": "NS" }, { "kind": "dns#resourceRecordSet", "name": "zeadle.org.", "rrdatas": [ "ns-cloud-b1.googledomains.com. dns-admin.google.com. 1 21600 3600 1209600 300" ], "ttl": 21600, "type": "SOA" }, { "kind": "dns#resourceRecordSet", "name": "www.zeadle.org.", "rrdatas": [ “xxx.xxx.xxx.xxx” ], "ttl": 3600, "type": "A" } ]

• 出力（ちっちゃくてすいません・・・

あとはdigとかdrillで @serverつけてテスト すれば返ってきます！

CloudSQL

• 今回は利用しません。

• ただみなさんに伝えたいこととして他社CloudのDBに比べると起動がすんごい速いので１回起動してみて頂けると・・・

• 現状は性能がでないけど”ちょっと使う”には非常に良いと思います。

• 今後の性能向上に期待してます！

管理上のメリット• Project単位で分割されている構造になっていて 課金周りもProject単位で分割されている。

• 自分のGoogleAppsのアカウントひとつだけで各種ProjectのDeveloperConsoleにアクセスできる！

• これは複数のProjectを扱う上で非常に大きなメリットになります。

• 同じくGoogleCloudSDKの各種Toolkitも--projectパラメーターでアクセスできるようになっているためすごい使いやすいです！

今後の予定• DeployTool作る！

• AutoScale作る！

• Configrationをどうするかmeta-serverかzookeeper使ってTemplateEngineと組み合わせて作る？

• OrchestrationをどれでやろうかなRedisのpub/sub, ZooKeeperのwatch, Serf？手段はたくさんあるので楽しいですね！

目標

• 前職で15万req/per secのソーシャルゲーム基板を作ることができました。

• 構成はオンプレミス + Windows + Fusion-IO + OpenSource

• 確かにソーシャルゲームが非常に盛り上がった時代の中心で達成できた数字で、これからそういった数字が出せるかわかりませんがそれを超えたいと考えています！

目指せ！ 25万req/per sec！！

大きなシステム作りたいですね！

スタートしたばかりの 時間もリソースも限られている 小さなチームですが 最大限クォリティあげてリリースします！

ご清聴ありがとうございました！ !

今後ともよろしくお願い致します！