SlideShare a Scribd company logo

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

•
•
Katsutoshi Nagaoka
Katsutoshi Nagaoka

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

1 of 56
Downloaded 33 times
AWS と GCP を使用したインフラ環境 Katsutoshi NAGAOKA Server-side Software Engineer Takusuta Tech Conference #1
永岡 克利 (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
Outline • サービス紹介 • AWS を使用したインフラ環境 • GCP を使用したインフラ環境 • まとめ
サービス紹介
ライブ配信サービス Takusuta Web PageiPhone & Android App
AWS を使用したインフラ環境
• AWS • EC2 • API Server • S3 • Static Content • GCP • BigQuery 開発時∼リリース初期の構成 AWS Route53 CloudFront S3 EC2 MongoDBELB BigQuery GCP StackDriverSlack AeroSpike
AWS でのインフラ構築 • VPC 設計は考えることが沢山 • Subnet • Internet Gateway • Routing Table • Security Group • NAT • VPN • DNS (Route53) • AMI …etc • これらの作業を管理コンソールで行うのは…
AWSとGCPを使用したインフラ環境
NO!
Yes! Terraform!
Terraform とは • Hashicorp 社製のオーケストレーションツール • インフラ構成をコード管理 • インフラ構成の変更をバージョン管理 • 主要な AWS リソースを網羅している 1. 構成ファイル 2. 実行計画 3. 自動生成
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" } }
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" } }
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" } }
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" }
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}" }
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)}"
 ] }
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" }
実際使ってみて • 新しくインフラ構築する場合は凄く便利 • 変更内容をレビューできる • コード化によって属人化が無くなった • 再構築が非常に楽なので気軽に使い捨てできる（開発環境など） • 何でもできるけど不向きもある • 状態を持つリソース（ELBなど）は Terraform の管理下におかない • 各インスタンス固有の設定は Ansible で行っている • インスタンススペックの変更は結構辛い • 例: MongoDB Cluster のオンラインスケールアップ
実際使ってみて • バージョンアップがクッソはやい • 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 は要チェック
GCP を使用したインフラ環境
Takusuta Web https://takusuta.com/ V1 V2 V3 : coming soon
Takusuta Web https://takusuta.com/ Jul Aug Sep Oct Nov AWS (S3 Static Content) Goole Cloud Platform V1 V2 V3
• AWS • EC2 • API Server • S3 • Static Content • GCP • BigQuery 開発時 リリース初期の構成 AWS Route53 CloudFront S3 EC2 MongoDBELB BigQuery GCP StackDriverSlack AeroSpike
• 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
理由 • GKEを使ってみたかった
使ってみたら • いろいろと驚いた
GKE とは • Kubernetes のフルマネージドサービス • Generally Available • Docker コンテナの管理ツール • GCE 上に Kubernetes Cluster を構築 • クラスタのリサイズ • コンテナのグルーピング • コンテナの自動配置 • コンテナのリサイズ • コンテナの負荷分散
GKE の用語 • Pod • コンテナのグループ • 1コンテナ以上で作成 • Replication Controller (RC) • Pod のレプリカ管理 • 管理下の Pod のリサイズを担当 Pod GKE Node Pod Pod GKE Node Pod Pod Pod RC Management Pod Replica
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
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
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
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
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
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
Cross Region LB
Regions • Features • Haswell [2013 ] • Lvy Bridge [2012 ] • Sandy Bridge [2011 ] https://cloud.google.com/compute/docs/zones
GCP でのインフラ構築 • GKE • Cluster • RC • Service • GCE-LB • Backend • Url Map • HTTPS LB … etc • AWS より考える要素が少ないが、管理コンソールで行うのは…
AWSとGCPを使用したインフラ環境
NO THANKS!
公式ツールで十分
Cloud SDK とは • Google 社製の GCP 管理ツール群 • gcloud • GKE Cluster を作成 • GCE HTTPS-LB を作成 (beta) • kubectl • Kubernetes Cluster Manager の管理
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"
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
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
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}"
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"
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"
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}
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"

実際使ってみて • Production 環境で Docker を使える時代になった • GKE なら本番環境ですら使い捨てできる • Cluster 作成から Deploy → Service IN まで 10 分未満 • GKE と Cloud Monitoring, Cloud Logging の連携も容易 • Cross-Region HTTPS LB の破壊力を体感
実際使ってみて • GKE 以外は GA になっていない • Cloud Logging • 標準機能を使うと 1Pod = 1Log, ログレベルを指定できない • BigQuery への Export が貧弱 • Cloud Monitoring • 取得できるメトリックスが少ない • 初期状態では GKE Node に StackDriver Agent がない • GCE-LB • エラー画面 (502, 503) をカスタマイズできない
まとめ
Takusuta のインフラ環境 • 初期は AWS を使用していたが、徐々に GCP を本番投入している • GKE によるコンテナ管理は非常に魅力的で、積極的に使っていきたい
Thank you

More Related Content

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 を使用したインフラ環境 • まとめ
  • 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!
  • 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 は要チェック
  • 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
  • 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
  • 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 より考える要素が少ないが、管理コンソールで行うのは…
  • 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) をカスタマイズできない
  • 55. Takusuta のインフラ環境 • 初期は AWS を使用していたが、徐々に GCP を本番投入している • GKE によるコンテナ管理は非常に魅力的で、積極的に使っていきたい