TakusutaTechConf #1 での発表資料です。 http://connpass.com/event/21361/

1. AWS と GCP を使用したインフラ環境
Katsutoshi NAGAOKA
Server-side Software Engineer
Takusuta Tech Conference #1

2. 永岡 克利 (Katsutoshi NAGAOKA)
• 酒好き Software Engineer
• CyberAgent: 社内向け基盤システム開発 (2011-2014)
画像変換 API, 掲示板 API, NoSQL database service の開発
#Java #C++ #ImageMagick #MySQL #kumofs #Cassandra
• 株式会社タクスタに JOIN (2015-)
サーバサイドの開発（こっちがメイン）とインフラ全般を担当
#Golang #Python #Node.js #MongoDB #Redis #AWS #GCP
@na_ga
About me

3. Outline
• サービス紹介
• AWS を使用したインフラ環境
• GCP を使用したインフラ環境
• まとめ

4. サービス紹介

5. ライブ配信サービス Takusuta
Web PageiPhone & Android App

6. AWS を使用したインフラ環境

7. • AWS
• EC2
• API Server
• S3
• Static Content
• GCP
• BigQuery
開発時∼リリース初期の構成
AWS
Route53
CloudFront S3
EC2 MongoDBELB
BigQuery
GCP
StackDriverSlack
AeroSpike

8. AWS でのインフラ構築
• VPC 設計は考えることが沢山
• Subnet
• Internet Gateway
• Routing Table
• Security Group
• NAT
• VPN
• DNS (Route53)
• AMI …etc
• これらの作業を管理コンソールで行うのは…

10. NO!

11. Yes! Terraform!

12. Terraform とは
• Hashicorp 社製のオーケストレーションツール
• インフラ構成をコード管理
• インフラ構成の変更をバージョン管理
• 主要な AWS リソースを網羅している
1. 構成ファイル 2. 実行計画 3. 自動生成

13. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# vpc
resource "aws_vpc" "tkst_prd" {
cidr_block = "${var.vpc_ip_prefix}.192.0/21"
tags {
Name = "tkst_prd"
}
}

14. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# public subnet
resource "aws_subnet" "prd_public" {
vpc_id = "${aws_vpc.tkst_prd.id}"
cidr_block = "${var.vpc_ip_prefix}.192.0/22"
availability_zone = "${var.aws.availability_zone}"
map_public_ip_on_launch = "1"
tags {
Name = "prd_public"
}
}
# private subnet
resource "aws_subnet" "prd_private" {
vpc_id = "${aws_vpc.tkst_prd.id}"
cidr_block = "${var.vpc_ip_prefix}.196.0/22"
availability_zone = "${var.aws.availability_zone}"
map_public_ip_on_launch = "0"
tags {
Name = "prd_private"
}
}

15. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# internet gateway
resource "aws_internet_gateway" "prd_igw" {
vpc_id = "${aws_vpc.tkst_prd.id}"
tags {
Name = "prd_igw"
}
}

16. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# public route table
resource "aws_route_table" "prd_route_public" {
vpc_id = "${aws_vpc.tkst_prd.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.prd_igw.id}"
}
tags {
Name = "prd_route_public"
}
}
# private route table
resource "aws_route_table" "prd_route_private" {
vpc_id = "${aws_vpc.tkst_prd.id}"
route {
cidr_block = "0.0.0.0/0"
instance_id = "${aws_instance.prd_nat.id}"
}
tags {
Name = "prd_route_private"
}

17. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# security group
resource "aws_security_group" "ssh_all" {
name = "ssh-all"
description = "Allow all SSH traffic"
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags {
Name = "sg_ssh_all"
}
vpc_id = "${aws_vpc.tkst_prd.id}"
}

18. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# route53
resource "aws_route53_record" "prd_api_private" {
zone_id = "${var.route53_zones.takusuta_com}"
name = "api-${count.index}.in.takusuta.com"
count = "3"
type = "A"
ttl = "300"
records = [
"${element(aws_instance.prd_api.*.private_ip, count.index)}"
]
}

19. Terraform によるインフラ構築
• インフラ構成をコード化
• VPC
• Subnets
• Internet Gateway
• Routing Table
• Security Group
• Route53
• EC2 Instance
# ec2 instance
resource "aws_instance" "prd_api" {
count = 3
ami = “${var.amis.takusuta_centos}"
instance_type = "c3.xlarge"
key_name = "${var.aws.key_name}"
subnet_id = "${aws_subnet.prd_public.id}"
security_groups = ["${aws_security_group.sg_prd_default.id}",
"${aws_security_group.sg_prd_api.id}"]
root_block_device = {
volume_type = "gp2"
volume_size = 100
delete_on_termination = false
}
ephemeral_block_device = {
device_name = "/dev/xvdb"
virtual_name = "ephemeral0"
}
tags {
Name = "prd_api_${format("%03d", count.index)}"
Env = "prd"
}

20. 実際使ってみて
• 新しくインフラ構築する場合は凄く便利
• 変更内容をレビューできる
• コード化によって属人化が無くなった
• 再構築が非常に楽なので気軽に使い捨てできる（開発環境など）
• 何でもできるけど不向きもある
• 状態を持つリソース（ELBなど）は Terraform の管理下におかない
• 各インスタンス固有の設定は Ansible で行っている
• インスタンススペックの変更は結構辛い
• 例: MongoDB Cluster のオンラインスケールアップ

21. 実際使ってみて
• バージョンアップがクッソはやい
• 2015/05 検証段階では v0.4.x, 導入段階では v0.5.x
• 2015/07 初期リリース時期には v0.6.0
• 2015/10 最近 v0.6.4 にあげた
• 前のめりなアップデートをしてくる
• BACKWARDS INCOMPATIBILITIES
• けど v0.6.x からは比較的落ち着いてきた感じ
• Release Note と Github issues は要チェック

22. GCP を使用したインフラ環境

23. Takusuta Web
https://takusuta.com/
V1 V2 V3 : coming soon

24. Takusuta Web
https://takusuta.com/
Jul Aug Sep Oct Nov
AWS (S3 Static Content) Goole Cloud Platform
V1 V2 V3

25. • AWS
• EC2
• API Server
• S3
• Static Content
• GCP
• BigQuery
開発時 リリース初期の構成
AWS
Route53
CloudFront S3
EC2 MongoDBELB
BigQuery
GCP
StackDriverSlack
AeroSpike

26. • AWS
• EC2
• API Server
• S3
• Static Content
• GCP
• GKE
• Web Server
• BigQuery
Web V2 以降のインフラ構成
AWS
Route53
CloudFront S3
EC2 MongoDBELB
BigQuery
GCP
GKEGCE-LB
AeroSpike

27. 理由
• GKEを使ってみたかった

28. 使ってみたら
• いろいろと驚いた

29. GKE とは
• Kubernetes のフルマネージドサービス
• Generally Available
• Docker コンテナの管理ツール
• GCE 上に Kubernetes Cluster を構築
• クラスタのリサイズ
• コンテナのグルーピング
• コンテナの自動配置
• コンテナのリサイズ
• コンテナの負荷分散

30. GKE の用語
• Pod
• コンテナのグループ
• 1コンテナ以上で作成
• Replication Controller (RC)
• Pod のレプリカ管理
• 管理下の Pod のリサイズを担当
Pod
GKE Node
Pod Pod
GKE Node
Pod Pod Pod
RC
Management Pod Replica

31. GKE の用語
• Pod
• コンテナのグループ
• 1コンテナ以上で作成
• Replication Controller (RC)
• Pod のレプリカ管理
• 管理下の Pod のリサイズを担当
• Service
• Pod に対する LB みたいなやつ
• iptables で DNAT → kube-proxy
Pod
GKE Node
Pod Pod
GKE Node
Pod Pod Pod
Service RC
Layer3 Load Balancer

32. Web V2 以降のインフラ詳細構成
• GKE
• tkst-service
• tkst-rc
• tkst-pod
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
User
Admin
https://takusuta.com

33. Web V2 以降のインフラ詳細構成
• GKE
• tkst-service
• tkst-rc
• tkst-pod
• 問題点
• Service に証明書を設定不可
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
User
Admin
https://takusuta.com

34. Web V2 以降のインフラ詳細構成
• GCE-LB
• tkst-url-map
• tkst-backend
• GKE
• tkst-service
• tkst-rc
• tkst-pod
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
User
tkst-backend
tkst-url-map
HTTPS-LB
https://takusuta.com
Admin

35. Web V2 以降のインフラ詳細構成
• Multi Region
• Asia
• US
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
User from Japan
tkst-backend-us
https://takusuta.com
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
tkst-backend-asia
tkst-url-map
Cross-Region HTTPS-LB

36. Web V2 以降のインフラ詳細構成
• Multi Region
• Asia
• US
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
User from US
tkst-backend-us
tkst-url-map
Cross-Region HTTPS-LB
https://takusuta.com
tkst-pod
GKE NODE GKE NODE
tkst-service tkst-rc
tkst-pod
tkst-backend-asia

37. Cross Region LB

38. Regions
• Features
• Haswell [2013 ]
• Lvy Bridge [2012 ]
• Sandy Bridge [2011 ]
https://cloud.google.com/compute/docs/zones

39. GCP でのインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB … etc
• AWS より考える要素が少ないが、管理コンソールで行うのは…

41. NO THANKS!

42. 公式ツールで十分

43. Cloud SDK とは
• Google 社製の GCP 管理ツール群
• gcloud
• GKE Cluster を作成
• GCE HTTPS-LB を作成 (beta)
• kubectl
• Kubernetes Cluster Manager の管理

44. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create gke cluster
$ gcloud container clusters create "${CLUSTER_NAME}"
--zone "${REGION_ZONE}"
--machine-type "${MACHINE_TYPE}"
--num-nodes "3"
--scope "https://www.googleapis.com/auth/compute"
"https://www.googleapis.com/auth/devstorage.read_only"
"https://www.googleapis.com/auth/bigquery"
"https://www.googleapis.com/auth/logging.write"

45. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create replication controller
$ cat << EOS > ./tkst-rc.json; kubectl create -f ./tkst-rc.json
{
"kind": "ReplicationController",
"apiVersion": "v1",
"metadata": { "name": "tkst-rc", "labels": { "name": "tkst-rc" } },
"spec": {
"replicas": 2,
"selector": { "name": "tkst-rc-pods" },
"template": {
"metadata": { "labels": { "name": "tkst-rc-pods" } },
"spec": {
"containers": [ {
"name": "${IMAGE_NAME}",
"image": "${GCR_URL}/${IMAGE_NAME}:${TAG}",
"ports": [ { "containerPort":3000, "protocol":"TCP" } ]
} ]
}
}
}
}
EOS

46. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create service
$ cat << EOS > ./tkst-srv.json; kubectl create -f ./tkst-srv.json
{
"kind": "Service",
"apiVersion": "v1",
"metadata": { "name": "tkst-srv", "labels": { "name": "tkst-srv" } },
"spec": {
"type": "NodePort",
"ports": [ {
"name": "web",
"port": 3000,
"targetPort": 3000,
"nodePort": 30000
} ],
"selector": {
"name": "tkst-rc-pods"
}
}
}
EOS

47. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create backend
$ gcloud beta compute backend-services add-backend "tkst-backend"
--instance-group "${GKE_INSTANCE_GROUP}"

48. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create url map
$ gcloud beta compute url-maps create "tkst-https-lb"
--default-service "tkst-backend"

49. Cloud SDK によるインフラ構築
• GKE
• Cluster
• RC
• Service
• GCE-LB
• Backend
• Url Map
• HTTPS LB
# create target https proxy
$ gcloud beta compute target-https-proxies create "tkst-https-lb-proxy"
--url-map "tkst-https-lb"
--ssl-certificate "${SSL_CERTIFICATE}"
# create forwarding rule
$ gcloud beta compute forwarding-rules create "tkst-https-lb-forward"
--global
--address "${LB_GLOBAL_IP}"
--port-range "443"
--target-https-proxy "tkst-https-lb-proxy"

50. GKE でのスケール
• scale cluster
• group name
• size=[num]
• scale rc
• rc name
• replicas=[num]
# resizing cluster
$ gcloud compute instance-groups managed resize ${GKE_INSTANCE_GROUP}
--size ${SIZE}
# resizing pod of the rc
$ kubectl scale rc ${CLUSTER_NAME}-tkst-rc
-—replicas=${REPLICAS}

51. GKE でのリリース
• upload image
• docker build
• docker tag
• docker push
• rolling update
• rc name
• image
• update-period=[sec]
# upload image to GCR
$ docker build
$ docker tag -f tkst/${IMAGE_NAME} ${GCR_DOMAIN}/${IMAGE_NAME}:${TAG}
$ gcloud docker push ${GCR_DOMAIN}/${IMAGE_NAME}:${TAG}
# rolling update
$ kubectl rolling-update ${CLUSTER_NAME}-tkst-rc
-—image="${GCR_URL}/${IMAGE_NAME}:${TAG}"
--update-period="10s"

52. 実際使ってみて
• Production 環境で Docker を使える時代になった
• GKE なら本番環境ですら使い捨てできる
• Cluster 作成から Deploy → Service IN まで 10 分未満
• GKE と Cloud Monitoring, Cloud Logging の連携も容易
• Cross-Region HTTPS LB の破壊力を体感

53. 実際使ってみて
• GKE 以外は GA になっていない
• Cloud Logging
• 標準機能を使うと 1Pod = 1Log, ログレベルを指定できない
• BigQuery への Export が貧弱
• Cloud Monitoring
• 取得できるメトリックスが少ない
• 初期状態では GKE Node に StackDriver Agent がない
• GCE-LB
• エラー画面 (502, 503) をカスタマイズできない

54. まとめ

55. Takusuta のインフラ環境
• 初期は AWS を使用していたが、徐々に GCP を本番投入している
• GKE によるコンテナ管理は非常に魅力的で、積極的に使っていきたい

56. Thank you