AWSとGCPを使用したインフラ環境

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 • これらの作業を管理コンソールで行うのは…

9. NO!

10. Yes! Terraform!

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

12. 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" } }

13. 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" } }

14. 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" } }

15. 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" }

16. 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}" }

17. 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)}"  ] }

18. 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" }

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

20. 実際使ってみて • バージョンアップがクッソはやい • 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 は要チェック

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

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

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

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

25. • 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

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

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

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

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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. Cross Region LB

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

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

39. NO THANKS!

40. 公式ツールで十分

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

42. 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"

43. 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

44. 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

45. 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}"

46. 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"

47. 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"

48. 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}

49. 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" 

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

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

52. まとめ

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

54. Thank you

AWSとGCPを使用したインフラ環境

Katsutoshi Nagaoka

AWSとGCPを使用したインフラ環境

A particular slide catching your eye?