Wordpress案件にgkeを採用してみた(短縮版)

案件に
Yu Amano
hbseminar #1
Google Cloud Platformの基礎とGCP・GKEの事例紹介
2017/8/23
GKEを採用してみた

インフォバーングループ本社
✘ インフラエンジニア
○ クライアント案件や自社メディアのインフラ全般
✘ 情報システム室
○ 社内サーバ(AD etc)やネットワーク全般
#個人ではGKEでマストドンやNextCloudなどを運用しておりま
す。
楽器(ドラムとギター)と水草水槽を趣味としております。
About me
天野優(Yu Amano)
@amanoyu

Outline
✘ これまでのGoogle Cloud Platformの採用経歴について
✘ GKE採用前のDockerコンテナの利用状況
✘ DockerとGKEを本番環境として導入検討した動機、経緯
✘ 弊社WordPress GKE環境のシステム構成
✘ Dockerコンテナのオーケストレーションツールの選択
✘ 複数のWordPressを管理する手段
✘ まとめ
✘ 今後の課題、または引き続き導入検討していきたい事

インフォバーングループと事業内容
サービス・
機能
ソリューション事業メディア事業事業区分
メディア運営
広告商材の提供
物販サービスの提供
リサーチ/UXコンサルティング
ネイティブ広告の企画・販売・運用
ネイティブ広告の仕入・商品企画
（株）インフォバーン
提供会社
既存メディアを活用した
コミュニケーションを提供
企業独自のオウンドメディアを中心とし
た
コミュニケーションを構築・運営
Webメディア
広告代理店
戦略
自社Web
メディア
企画・制作
（株）インフォバーン
１２のメディアブランドを
運営するメディアカンパニー
企業のマーケティング活動をコンテンツとメディアでサポートする
デジタルエージェンシー
All rights reserved Infobahn Inc.2016 CONFIDENTIAL

１２の自社メディアブランドを展開、外部専売メディアも販売を開始
男性・女性問わず、ライフスタイルからビジネスシーンまで、さまざまなターゲット層にリーチするメディアを運営。

オウンドメディアのプロジェクト実績
業界を代表する大企業のオウンドメディア企画・制作実績多数
資生堂、花王、サントリーホールディングス、富士通、RICHO、シチズン時計、日本経済新聞、
ダイレクト出版、リクルート、日本IBM、ワコール、TIPNESS、　...他
All rights reserved Infobahn Inc.2016 CONFIDENTIAL

これまでの弊社の
Google Cloud Platform
採用経歴について

採用している本番環境のクラウド基盤は、やっぱ
り今も昔ももっぱらAWSが多いです。
やっぱりなんだかんだ
デファクトスタンダードな感
じになっちゃってますもん
ね〜

AWS以外では、、、
割合としては少ないながらも、案件によっては
下記クラウド基盤も採用
✘ IBM Bluemix Infrastructure(旧SoftLayer)
✘ さくらのクラウド
✘ IDCFクラウド

本セミナーの主役、GCPは、、、
AWSを使っているとなかなか他のクラウド基盤を使う機会が少
ないですよね。
弊社も検証レベルで、試しにGoogle Compute Engineで構築
してみる。
といった事はやっていたものの、本番環境に採用という事には
至っておりませんでした。
興味は
あるんだけどねぇ

✘ 2015年11月頃
○ 自社メディア会員システムのリニューアル計画が発動
○ 試しに試算したら想定インフラ構成をAWSで構築するよ
り、GCPで構築した方がサーバ代が低コストになりそうだっ
た。
○ チャレンジだが今まで蓄積した知見を元に本番環境に採
用し、運用知見もためよう！
GCPの本番環境採用の転機は、、、

GCP環境にリニューアル構築したサーバ構成はこんな感じ
になっておりました。実は今は既にクロージングしたシステ
ムです汗
あまり詳しくお話し出来ませんが、、、
当時はまだ
CloudSQLを本番環
境に採用するには不
安がありDBは自前で
構築していました。

当時、利用したGCPのサービスとしては、
✘ Google Compute Engine
✘ Google Cloud Storage
✘ Google Cloud Load Balancing
と、そこまで多くのサービスは採用しませんでしたが、
この知見が今回のGKE 本番環境に活きております。

GKE採用前の
弊社での
Dockerコンテナの利用状況

✘ 本番環境でのDockerコンテナの採用はゼロ。
✘ 自社メディアCMSの開発部隊では、ローカル開発環境として
Dockerコンテナを採用
○ Docker Composeで簡易的な本番環境を再現
✘ クライアント案件では検証程度で、自社メディアCMS開発部隊
と比べると然程活発には利用されていなかった。
○ 鋭意啓蒙中な状況
基本、開発環境用にとどまっていた

DockerとGKEを
本番環境として
導入検討した動機、経緯

AWS採用環境では下記ツールを採用し、インフラのコード化は実
施しておりました。
✘ Terraform
○ AWSでの下記サービスの構築に利用
VPC　CloudFront
ALB　EC2
RDS　S3
✘ Ansible
○ EC2へのOSセットアップから始まり、ミドルウェアの設定、
弊社カスタマイズのWordPressインストール
まず、AWS上でのインフラ構築手段について

AWS
Route53 CloudFront ALB
EC2
EC2
RDS
①TerraformでAWS環境を構築
②AnsibleでWordPress部分まで構築

以前より、常々思っていたのが、、、
✘ TerraformとAnsibleで構築しているWP環境をDockerfile化
し、コンテナでの運用にしたら、
○ 初期構築期間を短くし、より構築コストを抑えられないか
○ 管理コストも下がらないかしら
○ メンテナンスもDockerイメージの差替えで済むようにならないか
→ブルーグリーンデプロイメントを意識
WordPress案件のインフラ構成の標準化はある程度出来ており、
後はどれだけインフラ環境の払出しを、シンプル且つ低コストにす
るかという事を検討をしておりました。

きっかけは２つの案件
✘ 2017年2月頃
○ Rubyフルスクラッチ開発したCMSで展開した自社サービス
のWP化
■ 複数のサイトをマイグレーションする必要がある
○ 弊社広報用イベントサイト管理システムの構築
■ イベント毎に独立したWPを展開したいらしい

どちらも低予算！！
通常のクライアント案件の費用感では
到底対応は無理(；´Д｀)

✘ 正直言うと、2016年12月頃から個人サーバ環境にGKEを使
い始めていてWordPressで運用している個人ブログもGKE
に移管していました汗
⬇
✘ ベースとなる知見は(個人的に)ある程度あった
○ 企業の本番環境でも、いけるんとちゃうか？感はあった。
✘ GKEクラスター環境の費用をマイグレーション対象サイトで
按分すれば低予算を実現出来るかも、、、
○ 予算的にもいけるやん！！
やっとGKE登場です

弊社WordPress GKE環境の
システム構成

GCR
(コンテナリポジトリ)
GKE Node #1 Node #2 Node #3Pod(WP-1)
Docker
コンテナ
Pod(WP-2)
Docker
コンテナ
Pod(WP-3)
Docker
コンテナ
Pod(WP-4)
Docker
コンテナ
Pod(WP-5)
Docker
コンテナ
Pod(WP-6)
Docker
コンテナ
MySQL MySQL MySQL MySQL MySQL MySQL
DB
(WP-1)
DB
(WP-2)
DB
(WP-3)
DB
(WP-4)
DB
(WP-5)
DB
(WP-6)
Docu
ment
Root
(WP-1)
Docu
ment
Root
(WP-2)
Docu
ment
Root
(WP-3)
Docu
ment
Root
(WP-4)
Docu
ment
Root
(WP-5)
Docum
ent
Root
(WP-6)
CloudSQL Storage
全体としては
こんな感じ

GCR
Docker
コンテナ
Pod(WP-2)
Docker
コンテナ
Pod(WP-3)
Docker
コンテナ
Pod(WP-4)
Docker
コンテナ
Pod(WP-5)
Docker
コンテナ
Pod(WP-6)
Docker
コンテナ
DB
(WP-1)
DB
(WP-2)
DB
(WP-3)
DB
(WP-4)
DB
(WP-5)
DB
(WP-6)
Docu
ment
Root
(WP-1)
Docu
ment
Root
(WP-2)
Docu
ment
Root
(WP-3)
Docu
ment
Root
(WP-4)
Docu
ment
Root
(WP-5)
Docum
ent
Root
(WP-6)
CloudSQL Storage
WordPressが動作するDockerコンテナのイメージ管理
・Bitbucketで諸々のソースを管理
・CircleCI(ver2.0)でDockerファイルをイメージにbuild
・buildしたDockerコンテナイメージはCircleCIからGCRにプッシュ
・GKE上に展開しているコンテナはGCR上のイメージを利用

GCR
Docker
コンテナ
Pod(WP-2)
Docker
コンテナ
Pod(WP-3)
Docker
コンテナ
Pod(WP-4)
Docker
コンテナ
Pod(WP-5)
Docker
コンテナ
Pod(WP-6)
Docker
コンテナ
DB
(WP-1)
DB
(WP-2)
DB
(WP-3)
DB
(WP-4)
DB
(WP-5)
DB
(WP-6)
Docu
ment
Root
(WP-1)
Docu
ment
Root
(WP-2)
Docu
ment
Root
(WP-3)
Docu
ment
Root
(WP-4)
Docu
ment
Root
(WP-5)
Docum
ent
Root
(WP-6)
CloudSQL Storage
MainWPでWordPressを一括管理
複数あるWordPressは
MainWPというWPを一括管理出来る
ツールを利用

GCR
Docker
コンテナ
Pod(WP-2)
Docker
コンテナ
Pod(WP-3)
Docker
コンテナ
Pod(WP-4)
Docker
コンテナ
Pod(WP-5)
Docker
コンテナ
Pod(WP-6)
Docker
コンテナ
DB
(WP-1)
DB
(WP-2)
DB
(WP-3)
DB
(WP-4)
DB
(WP-5)
DB
(WP-6)
Docu
ment
Root
(WP-1)
Docu
ment
Root
(WP-2)
Docu
ment
Root
(WP-3)
Docu
ment
Root
(WP-4)
Docu
ment
Root
(WP-5)
Docum
ent
Root
(WP-6)
CloudSQL Storage
GKE部分
・現状は1サイト1Podで運用している
・DBはCloudSQL(第２世代)を利用
・永続ストレージはGCEの永続ディスクをPodに直接接続

GKE部分によりフォーカス

の前に、改めてGKEについて
✘ Kubernetesのフルマネージドサービス
○ Dockerコンテナを実行するためのクラスタ管理、
オーケストレーションシステム
○ GCE上にKubernetes Clusterを構築
■ クラスタのリサイズ
■ コンテナのグルーピング
■ コンテナの自動配置と自動復旧
■ コンテナのリサイズ
■ コンテナの負荷分散

✘ Clusterの各node料金はGCE料金が適用される
✘ Clusterの料金はNode数によって異なる
○ 5Nodeまでは無料
○ 6Node以上で＄0.20 hour / Cluster (東京リージョン)
＄146 month / Cluster (東京リージョン)
GKEの料金
時間課金
月額
Masterはカウントさ
れないんです

✘ 基本はGoogle Cloud SDKを利用するのが良い
○ Google社製のGCP管理ツール群(CLI)
■ gcloud
● GCP全般のCLI
● GKE関連ではClusterの管理を行う
■ kubectl
● 名前の通りkubernetes周りの操作
GKEのオペレーションについて

✘ GKEに限らず、GCPのオペレーションにおいて、Google
Cloud Shellが便利
○ ブラウザベースのコマンドライン環境
○ Google Cloud SDK導入済みなので、ローカルマシンにイ
ンストールしなくてもよい。
○ 何気にCloudSQLにMySQLコマンドで接続したい時など
に重宝する
○ 仕組みとしては、Compute Engineの仮装マシン(debian
ベースのLinux)が起動して、その仮装マシンをブラウザか
ら操作できるといったもの。（利用料金は発生しない）
GKEのオペレーションについて

✘ Pod
○ コンテナのグループ化したもの
○ Pod単位で作成、開始、停止、削除の操作を行う
GKEの用語

✘ Deployment
○ ReplicaSetを生成し、管理し、ローリングアップデートや
ロールバックといったデプロイ管理の仕組みを提供する
もの
✘ ReplicaSet
○ 同じ仕様のPodのレプリカ数を管理するもの
○ Podがレプリカ数より足りない場合はPodを追加し、多い
場合はPodを削除。この仕組みによってノードの障害や
アプリケーションのクラッシュでPodが足りなくなった際も
自動的にPodが追加され、セルフヒーリングが実現され
る。

Deploymentの仕組み
[Deployment]
my-wp
[ReplicaSet]
my-wp-1111
[Pod]
my-wp-1111
[Pod]
my-wp-2222
ReplicaSetを管理
Podの数(レプリカ数)を管理

Deploymentの仕組み(ローリングアップデート)
[Deployment]
my-wpアップデート前のReplicaSet
[ReplicaSet]
my-wp-1111
[Pod]
my-wp-1111
[Pod]
my-wp-2222
[ReplicaSet]
my-wp-1111
[Pod]
my-wp-3333
[Pod]
my-wp-4444
新しいReplicaSetが作られる
V1
V1 V1
V2
V2 V2
Pod数が減り最終的にゼロになる Pod数が増え最終的に元の数
に
コンテナイメージのバージョンアップなどアップデートがあった場合の動き
⇒

Deploymentの仕組み(ロールバック)
ローリングアップデートが終わった後もアップデート前の
ReplicaSetは一定数保持される。
これによりロールバックが可能となる。
[Deployment]
my-wp
[ReplicaSet]
my-wp-4444
[Pod]
my-wp-3333
[Pod]
my-wp-4444
[ReplicaSet]
my-wp-3333
[ReplicaSet]
my-wp-2222
[ReplicaSet]
my-wp-1111

✘ Service
○ Podが外部と疎通するための仕組み
■ type:NodePort
● kubernetesの内部ネットワークでの接続ポートを
設定
■ type: LoadBalancer
● TCP ロードバランサ(L4)
● SSLターミネーションは出来ない
✘ Ingress
○ HTTP(S) ロードバランサ(L7)
○ Serviceではなく、type:NodePortと併用し利用する
○ GCPのHTTP(S)ロードバランサをプロビジョニングする機
能
○ SSLターミネーションが可能
○ CloudCDNを利用出来る

User
https://aaa.infobahn.co.jp/
https://bbb.infobahn.co.jp/
https://ccc.infobahn.co.jp/
Ingress
type: NodePort
WordPress
Pod
aaaサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
bbbサイト cccサイト
Admin
Ingress
type: NodePort
WordPress
Pod
dddサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
eeeサイト
https://ddd.service.jp/
https://eee.service.jp/
Admin Admin Admin Admin

User
Ingress
type: NodePort
WordPress
Pod
aaaサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
Admin
Ingress
type: NodePort
WordPress
Pod
dddサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
eeeサイト
● Ingressはドメイン毎に払い出す。
● ワイルドカードSSL証明書をIngressに設定しSSLターミネーショ
ンをさせる
● Ingressの設定内でサブドメイン毎に振り分けるPod(厳密には
NodePort)を指定する

User
Ingress
type: NodePort
WordPress
Pod
aaaサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
Admin
Ingress
type: NodePort
WordPress
Pod
dddサイト
type:
LoadBalancer
type: NodePort
WordPress
Pod
type:
LoadBalancer
eeeサイト
IngressはHTTP(S)Load Balancerなので、80,443以外は疎通出来ない。
type: LoadBalancerを使用し、SSH、SFTP接続用ポートを空ける。
WordPressの運用をするにあたり、社内のフロントエンジニアやバックエンド
エンジニアはコンテナで動いている事を意識せず、Dockerやkubernetesの
知識がなくてもVPS感覚で利用出来る環境を目指した。

Dockerコンテナの
オーケストレーションツール
の選択について

検討、検証したのは、
✘ Docker Datacenter
✘ Kubernetesそのもの
✘ Mesos+Marathon+Docker
✘ Rancher
✘ Amazon EC2 Container Service (ECS)
✘ Google Container Engine
なぜGoogle Container Engineにしたのか

✘ Kubernetesのフルマネージドサービスとして非常に使いや
すい
○ MasterやDockerレジストリの管理が不要なのが大き
い
○ Kubernetesが今のところDockerオーケストレーション
としてナレッジの汎用性がありそう
✘ OSSによる活溌な開発とアップデート
○ 機能追加、拡充が積極的に行われている
✘ Stackdriverとの連携
○ リソース監視
○ 死活監視
○ ロギング
なぜGoogle Container Engineにしたのか

複数のWordPressを管理する手段

GCR
Docker
コンテナ
Pod(WP-2)
Docker
コンテナ
Pod(WP-3)
Docker
コンテナ
Pod(WP-4)
Docker
コンテナ
Pod(WP-5)
Docker
コンテナ
Pod(WP-6)
Docker
コンテナ
DB
(WP-1)
DB
(WP-2)
DB
(WP-3)
DB
(WP-4)
DB
(WP-5)
DB
(WP-6)
Docu
ment
Root
(WP-1)
Docu
ment
Root
(WP-2)
Docu
ment
Root
(WP-3)
Docu
ment
Root
(WP-4)
Docu
ment
Root
(WP-5)
Docum
ent
Root
(WP-6)
CloudSQL Storage
MainWPでWordPressを一括管理
複数あるWordPressは
MainWPというWPを一括管理出来る
ツールを利用
コレ！

全てをコンテナ周りの仕組みに任せず、WordPress自体は別
のツールを使って一括管理する方向で、、、
MainWPはWordPressのプラグイン。
一元管理を行うメインサイトに「MainWP」プラグインをインス
トールし、
管理対象となるサイトにはクライアント用の「MainWP Child」
プラグインをインストールしてセキュリティIDで紐付けて管理対
象とする。
複数のWordPressはMainWPに管理を任せる

MainWPで出来る主なこと
✘ 管理しているWordPressサイトを一覧表示
✘ 管理しているWordPressを最新版に一括アップデート(自動化にも対
応)
✘ 各管理WPサイトやダッシュボードにアクセス
✘ 記事や固定ページをリモート投稿
　　※カテゴリの読み込み、指定も可能！
✘ 各管理WPサイトの過去記事をまとめて検索、更新、削除
✘ 各管理WPサイトのデータバックアップ
✘ 各管理サイトのテーマを追加、変更
✘ 各管理WPサイトのプラグインをリモートでインストール、有効/無効
化、アップデート
WordPressの管理画面で出来る事は、ほぼ全てMainWP管
理画面で出来る。
また、MainWP自体にプラグインを追加する事で機能拡充が
出来る(セキュリティ簡易チェックや死活監視等)

簡易セキュリティスキャン

管理サイトからまとめて記事メンテ

WordPress案件にGKEを採用してみて、、、
✘ 環境の払出しはかなり楽。
✘ 諸々のコストについても、だいたい1/3くらいには抑えられそう
✘ GKEでのコンテナ管理は非常に魅力的、、、むしろ好き。
✘ 開発環境との環境差がなくなり便利
✘ DockerfileやGKEのコンフィグファイルを全てコード管理出来
る
✘ まだまだ数ヶ月の本番運用実績だが、ハートビーツさんとどん
どんナレッジを貯めて活用していきたい

今後の課題、
引き続き導入検討していきたい事

今後の課題、引き続き導入検討していきたい事
✘ Multi-Zone対応するため、永続ストレージ部分を共有スト
レージ、もしくは分散ストレージに移行
○ 現在利用しているGCEの永続ディスクはzone跨ぎが出来
ない。GKECluster自体はMulti-Zoneに対応しているが、
永続ディスクが不可なため、結果、現在の弊社環境は
Single-Zone構成になっている
○ NFS、GlusterFS、Rook、LonghornやOpenEBSなど幅
広く検証していきたい
✘ CI/CDツールの組み込みをより進めていきたい
✘ GKEClusterのリソース管理
○ Requests、Limitsの最適化
○ オートスケール

ご清聴いただき
ありがとうございました

Wordpress案件にgkeを採用してみた(短縮版)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Wordpress案件にgkeを採用してみた(短縮版)

Similar to Wordpress案件にgkeを採用してみた(短縮版) (20)

Recently uploaded

Recently uploaded (6)

Wordpress案件にgkeを採用してみた(短縮版)