Docker/Kubernetes 実践コンテナ開発入門

技術評論社様、著者の山田さんからご恵贈いただきましてありがとうございます。

かなり分厚い本で、内容も濃いので読むのに時間がかかりましたが簡単に感想を書いていきます。

TL;DR

• Production環境でDockerを利用している人でも学びが多い一冊
• Kubernetesに対応したDocker for Mac/Windowsが2018年07月に正式リリースされ、手軽にKubernetesが動かせるようになったいま、Kubernetesの初学書として最適
• 実際にDockerでサービスを運用してきた著者ならではの視点で語られているコラムが非常に興味深い

前提

書評の前に私のDocker歴について簡単に書いておきます。

• JAWS-UG コンテナ支部で登壇経験あり
• Dockerに関する基本的な知識は習得済み
• Amazon ECSを利用して2年ほど前からProduction環境でDocker運用中
• Kubernetesは理解不足
• 役職が変わってここ1年くらいからDockerと周辺技術の最新情報がキャッチアップ出来てない 😓

目次

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1.Dockerの基礎
2.Dockerコンテナのデプロイ
3.実用的なコンテナの構築とデプロイ
4.Swarmによる実践的なアプリケーション構築
5.Kubernetes入門
6.Kubernetesのデプロイ・クラスタ構築
7.Kubernetesの発展的な利用
8.コンテナの運用
9.より軽量なDockerイメージを作る
10.Dockerの様々な活用方法

Appendix-A セキュリティ
Appendix-B Dockerでの開発を支援するツール・サービス
Appendix-C 主要コマンドまとめ

書評

Docker

Dockerと周辺技術は変化の速度が非常に早く、情報キャッチアップのコストが高く、Web上にある情報もすぐ陳腐化して大半が役に立たないので、 私はかねてから公式ドキュメントを読むのが最も良いというスタンスだったのですが、 本書は公式ドキュメントの内容はもちろんカバーされており、運用周りに関しては公式ドキュメント以上の内容が書かれている。

Kubernetes

Kubernetesに関しては一番丁寧に手厚く解説されているので、Minikubeで一度挫折したことがある私にとっては、 サンプルコードを書いてサクサク進めることが出来たので、Kubernetesの採用の足がかりになりそうです。 先月リリースされたDocker for Mac/Windows(Stable)がKubernetesに対応しており、 手軽にKubernetes環境が用意出来るようになったので、Kubernetesをこれから始める人にも最適かと。

コラム

またコラムが大量にありどれも素晴らしいのですが、特に

• 環境変数を積極的に使う
• 認証情報をセキュアに環境変数へ設定する
• Alpine Linuxベースのイメージを採用するべきか否か
• DockerはVagrantの代替となるか?

においては、以前エンジニア同士で議論したことがある内容なので大変興味深かった。

コンテナの運用

運用部分は普段Amazon ECS上で運用しておりAWSに頼り切っている部分なので、 ログの保管、障害対策については、他社事例として大変参考になった。

本書を読むにあたって

本書のサンプルコマンドを実行するにあたり、BashやZshを事前に設定しておくことをオススメします。これがあるとないとでは効率が段違いです。 本当に重要です!!

• Command-line completion | Docker Documentation

まとめ

2018年においては、

• 公式ドキュメント
• Docker/Kubernetes 実践コンテナ開発入門

を読めば、Docker/Kubernetesに関しては十分なのではないかと思う。

実際私も社内のエンジニアにも「Docker/Kubernetesはこれを読めばOK」と薦めています。

大変オススメです。

参考

• Docker/Kubernetes 実践コンテナ開発入門 出版に寄せて · tehepero note(・ω<) 2.0

TL;DR

• GoReplayを利用して、Production環境のリクエストを複製し、Stagins環境、開発環境に投げる仕組みを作った
• インフラ構成の大きな変更無しで、手軽にProduction環境の実リクエストを複製し、開発、動作検証ができるようになった
• 2016年の弊社サービスのDocker化や、インフラ構成の大幅な変更、ミドルウェアのアップデート、アプリの改修時のバグ事前検知と事故防止に大いに役に立った

GoReplayの説明

• GoReplay

• Goで書かれており、バイナリを設置し、オプションを指定し実行するだけで動作する
• アプリが稼働しているサーバで動く。(例えばNginx+Railsが稼働しているサーバで一緒にGoReplayを動かす感じ。)
• libpcap を利用しているので、tpcdumpと同じでデータリンク層(OSI layer2)レベルでパケットを取得しています。
• GoReplay は gor listen と gor replay の2つが1セットで動作します。
  • gor listen がリクエストを複製し、App と gor replay に渡す。
  • gor replay がリクエストを転送したり、ファイルに書き込んだり、再生作業をする。
• 複製の割合や、複数の転送先、リクエストのフィルタリング設定などがあり高機能。
  • https://github.com/buger/goreplay/wiki

私の理解が正しければ下記のような感じで動作してます。

Shadow Proxyとの比較

• アプリサーバで必要な時に手軽に動かせる。
• 動作が軽快
• インフラ構成的に利用時に事故が起こりにくい(サービスの全リクエストを裁くわけではないので)

今回なぜShadow Proxyを利用しなかったのかは後述。

実際に稼働している例で説明

実際に弊社で動かしている環境をざっくり図にして説明。

• Productionリリース予定のコードがデプロイされている、Stagingサーバを用意。
• Production frontendの１台で、GoReplayを動かしリクエストを複製し、ステージングサーバStaging frontendにリクエストをProductionと同じリクエストを投げる。
• Productionのデータと一緒にならないように、ステージング用に staging aggregator と データ格納先の staging BigQuery を用意。
• 下記コマンドのような形で動かし、Productionの1台に流れてきたリクエストを10%の割合で複製し、ステージングサーバに転送します。
• echoサーバを作って、ベンチをとった結果(後述)、リクエストを100%複製し転送すると、パフォーマンスが劣化するので複製・転送の割合10%だけにしてます。
• 実際の運用ではSupervisordを利用して、GoReplayの軌道を管理
• 次期リリース予定のコードやインフラに問題があれば、StagingサーバのbugsnagなどがキャッチしてSlackにPostされる。

1

sudo gor --input-raw :8080 --output-http "http://stating901.example.com|10%"

GoReplay利用時のベンチマーク

nginx + echo-nginx-module を利用して、GoReplayの複製割合に応じてどれくらいパフォーマンスが劣化するか下記のような形でベンチマークを取得。

1

ab -n 10000 -c 100 http://hogemoge.example.com/hello

0%はGoReplayの利用無し、100%の場合はGoReplayで全トラフィックを複製して転送する。

GoReplayで転送率を100%にして、全トラフィックを複製かけるとパフォーマンスが劣化するので、インフラを増強しておく必要あり。

ここから余談で、どうしてShadow Proxyを導入しなかったのか過去の経験と個人的な意見をちょっと書いてみる。

リクエストを複製するShadow Proxyの話

リクエストを複製するShadow Proxyと呼ばれるものは昔から存在します。

• cookpad/kage: Kage (kah-geh) is a shadow proxy server to duplex HTTP requests
• lestrrat/p5-Geest: Port of Kage
• kentaro/delta: HTTP shadow proxy server written in Go

Shadow Proxy利用時の一般的な構成

Shadow Proxyの問題点(※1)

• 構成的にロードバランサの次あたりに存在(リクエスト処理する構成の前段の方に存在)するので非常に高い信頼性が求められる。
• 構成的に全リクエストがShadow Proxyを経由し、backendのサーバに到達するため、Shadow Proxyがボトルネックになりやすい。
  • 各種Shadow Proxyのベンチマーク Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita
• インフラの構成的にサービスの全リクエストを処理する必要があるので、気軽に利用出来ない。稼働中のサービスに後から投入しにくい
• 全リクエストがShadow Proxyを通過する構成になっていると、Shadow Proxyが落ちるとサービス全部落ちる
• 上記を解消しShadow Proxyを安定的に稼働しようとすると、インフラが複雑化して障害点が増えやすい

※1 2年以上前の経験から得た知見なので、もしかして今は違うかもしれませんが。

この仕組みを作ったおかげで、Production環境のリクエストを利用し事前に動作検証が出来るので、今年は事故も心理的な負担がだいぶ減ったと思う。

• AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した
• ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる

ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!)

その他弊社の前提情報

• GitHub + CircleCIが連携済み
• Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用
• DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施

準備

ALBとECSの設定については@inokaraさんのブログが詳しいので、そちらを参照ください。 今回はALBのDynamic Port Mappingは利用してません。

• Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ - ようへいの日々精進XP
• Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ（2）〜 AWS CLI で試す 〜 - ようへいの日々精進XP

デプロイフロー

デプロイフローは下記のような形になってます。

デプロイ前の稼働中の状態

• ALBは80,443ポートで稼働
• コンテナではnode.jsのアプリが3000ポートで稼働

デプロイ直後の状態

• CircleCI経由で、ecs-deployを実行し、新しいコンテナを作成。
• 新しいコンテナが起動すると、自動でALB配下に追加されアクセスを流れる
• 古いコンテナと新しいコンテナが混在する

ecs-deployは下記のような形で実行。CircleCI上ではAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY を環境変数に設定し、引数に利用しているregionを-r us-west-1を追加して実行してます。

1
2
3
4
5

ecs-deploy \
-c クラスター名 \
-n サービス名 \
-i xxxxxxxxxxxx.dkr.ecr.us-west-1.amazonaws.com/kaizenplatform/kaizen-xxxxxxxx:947 \
-t 300

デプロイ部分のdocker pushとecs-deploy合わせて1分半くらいで完了している。

デプロイ完了後の状態

• しばらくすると古いコンテナが破棄され、新しいコンテナだけで稼働する
• 一連の作業中にリクエストを流し続けて、サービスが停止しないことも確認

ecs-deployの実行が走ってから、新しいコンテナが起動し、古いコンテナが廃棄されるまで、 大体6分くらい要している。

ALBとECSの初期設定が結構面倒ですが、設定さえ終われば、 新旧コンテナの入れ替え、ALB配下への追加削除が自動で行われるようになるので大変便利。

引き続きDynamic Port Mappingを利用した構成も検証中。

参考

• Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ - ようへいの日々精進XP
• Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ（2）〜 AWS CLI で試す 〜 - ようへいの日々精進XP
• Git プッシュから Amazon ECS に自動デプロイする仕組みを構築する | ORIH

• Alpine LinuxなDockerイメージにServerspecを実行する環境をMacとCircleCI上に作った
• CircleCI環境では lxc-attach コマンドが必要なので、spec_helper.rb で環境差を吸収するようにした
• 今後よく利用しそうなので、流用しやすい形でGithubに置いておいた
  • glidenote/docker-alpine-serverspec-sample

前提

最近Kaizen Platform, Inc.で利用している一部Docker ImageをAmazon LinuxベースのものからAlpine Linuxベースのものに置き換え中。 Alpine Linuxについては@stormcat24さんのブログが一番参考になります。

今までDockerイメージにServerspecを実行するときには、コンテナ内でsshdを立てて、ssh経由でknife-soloでプロビジョニングを実行し、その後同じくssh経由でServerspecを流していた。

Alpine Linuxベースに切り替えてから、出来るだけイメージサイズを小さくするためにknife-soloは利用せずに、Dockerfile だけで構築している。(Dockerfileだけが良いかは現在検証中) knife-soloのためにコンテナ内でsshdを立てる必要はなくなったので、同じくssh経由で実行していたServerspecはdocker-api 経由で実行するようにした。

実行環境

• Mac OS X
  • ProductVersion: 10.11.6
  • Ruby 2.3.0
  • Docker 1.12.0
• CircleCI
  • Ruby 2.3.0
  • Docker 1.9.1-circleci-cp-workaround
• serverspec 2.36.0
• docker-api 1.31.0

実際の作業

ファイル構成

先に作業後のファイル構成を書いておくと下記のような感じになります。

1
2
3
4
5
6
7
8
9
10

.
├── Dockerfile
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── circle.yml
└── spec
    ├── docker
    │   └── package_spec.rb
    └── spec_helper.rb

Gemfile

Gemfileを用意して bundle install

1
2
3
4
5

source 'https://rubygems.org'

gem 'rake'
gem 'serverspec'
gem 'docker-api'

Dockerfile

Dockerfileを用意。debugしやすいようにbashだけ導入

1
2
3

FROM alpine:3.4

RUN apk add --no-cache bash

tagは docker-alpine-serverspec-sample としてbuild。

1

docker build -t docker-alpine-serverspec-sample .

Serverspec各種ファイル

serverspec-init で各種ファイルを作成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

⇒  serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/sample_spec.rb
 + spec/spec_helper.rb
 + Rakefile
 + .rspec

生成されるsampleのテストは利用しないので削除

1

rm -rf spec/localhost

ローカル用の spec_helper.rb

1
2
3
4
5
6
7
8
9

require 'serverspec'
require 'docker'

set :backend, :docker
set :docker_url, ENV["DOCKER_HOST"]
image = Docker::Image.build_from_dir('.')
set :docker_image, image.id

Excon.defaults[:ssl_verify_peer] = false

テストファイルの追加

ディレクトリの作成し、Dockerfileのパッケージインストールに対応するテスト spec/docker/package_spec.rb を追加

1

mkdir -p spec/docker/

1
2
3
4
5

require 'spec_helper'

describe package('bash') do
  it { should be_installed }
end

Serverspecの実行

テストの準備が整ったので、Serverspecを流してみる。

1

bundle exec rake spec

問題がなければ下記のようになる。

1
2
3
4
5

Package "bash"
  should be installed

Finished in 1.61 seconds (files took 0.67509 seconds to load)
1 example, 0 failures

CircleCI上での実行

ローカルに続いて、CircleCI環境でも動くようにする。

circle.yml の用意

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

machine:
  timezone: UTC
  ruby:
    version: 2.3.0
  services:
    - docker

dependencies:
  pre:
    - bundle install

test:
  pre:
    - docker version
    - docker info
    - docker build -t ${CIRCLE_PROJECT_REPONAME} . :
        timeout: 1200
    - docker run ${CIRCLE_PROJECT_REPONAME} &
    - sleep 5
  override:
    - bundle exec rspec
    - docker ps -a
    - docker images

CircleCI でも動くようにspec_helper.rbの修正

公式ドキュメント に記載されているようにCircleCIのDockerでは docker exec が利用できず、 lxc-attach コマンドを利用しないといけないので、spec_helper.rb でMacとの環境差を吸収し、同じコマンドでServerspecが流せるようにする。

元同僚の@ngsが自身のブログに書いていたのでそれを利用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

require 'serverspec'
require 'docker'

set :backend, :docker
set :docker_url, ENV["DOCKER_HOST"]
image = Docker::Image.build_from_dir('.')
set :docker_image, image.id

Excon.defaults[:ssl_verify_peer] = false

# https://circleci.com/docs/docker#docker-exec
if ENV['CIRCLECI']
  module Docker
    class Container
      def exec(command, opts = {}, &block)
        command[2] = command[2].inspect # ['/bin/sh', '-c', 'YOUR COMMAND']
        cmd = %Q{sudo lxc-attach -n #{self.id} -- #{command.join(' ')}}
        stdin, stdout, stderr, wait_thread = Open3.popen3 cmd
        [stdout.read, [stderr.read], wait_thread.value.exitstatus]
      end
      def remove(options={})
        # do not delete container
      end
      alias_method :delete, :remove
      alias_method :kill, :remove
    end
  end
end

これで、Mac上でもCircleCI上でも同じ

1

bundle exec rake spec

でテストが実行できるようになった。

↑の画像のように、イメージのサイズが非常に小さいAlpine Linuxに切り替えてからbuildもtestもすぐに完了するので生産性が高くなった。

参考

• Alpine カテゴリーの記事一覧 - tehepero note(・ω<)
• Continuous Integration and Delivery with Docker - CircleCI
• CircleCI で Docker Container を Serverspec でテストする - Atsushi Nagase
• Docker + Serverspec を使ってCircleCI 上でインフラのテストを実行する - Qiita

• 特定のホストのメトリクス
• 特定のサービスのメトリクス
• 特定のダッシュボード

などを見るときにページにアクセスして探すのに若干手間がかかるので、Alfredから瞬時に開けるようにWorkflowを作った。

• glidenote/alfred-mackerel-page-workflow

導入方法や使い方はREADMEを参照ください。 動作は下記のような感じになります。(サービスとダッシュボードを開く動作はキャプチャに秘匿情報が含まれているので割愛してます )

関連

• CircleCIのProjectページの移動が簡単になるAlfred Workflowを作った - Glide Note

GitHub Notifications

• Gitify - GitHub Notifications on your menu bar

GitHubのNotifications通知については、Gitifyを利用。 それまでは自分宛の通知はZapier使ってSlackに通知したり、Chrome Extensionとか使って検知してたんですが、 ステータスバーに通知するやつが自分にはあっていたので、半年くらい前から利用してます。

CircleCI Notifications

• nolaneo/SeaEye: OSX notifications for Circle CI builds

CircleCIの通知にはSeaEyeを利用。特定プロジェクトや、自分のビルドだけ通知などが設定ができるのが大変便利。

BitBar & Sensu Notifications

• ripienaar/sensu_bitbar: BitBar Sensu status plugin

rebuild.fm a132で話題に出ていたBitBarで、KAIZENで利用している監視システムSensuのPluginがあったので導入。 Sensuがアラートを検知した場合、Pagerduty経由で、Slack、メール、電話、スマホアプリへの通知などをしてくれるので、無くても良いんですが、ちょっとBitBarを利用してみたかったので導入。

これを機にメールとSlackでの通知も減らしたので作業に集中する時間が増えた(気がする)

参考

• Rebuild: Aftershow 132: Math Is Hard, Let’s Go Programming (higepon)

• glidenote/alfred-circleci-projects-workflow

CircleCIで利用するProject数が増えると、それぞれのページに移動するのが めちゃくちゃ面倒なので、CircleCIのProject移動が簡単になるAlfred Workflowを作りました。

インストール方法、使い方はREADMEを見ていただくことにして、 どんな感じで動作するのかgif animationにしてみました。

Projectページを開く

URL情報をcacheしているので、サクサク動作します。

各Projectのmasterブランチのstatusを確認する

その都度APIを叩いて確認しているので、レスポンスが遅めです。

CircleCIとAlfredを利用している方は是非ご活用ください。

2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、特集「CircleCIによる継続的インテグレーション入門」を執筆しました。

CircleCIによる継続的インテグレーション入門

私が現在所属するKaizen Platform, Inc.でもCircleCIをヘビーユーズしており、サーバ/インフラ部分においても、

1. インフラCI
2. 稼働中サーバへのプロビジョニング
3. DNSレコードの管理
4. Terraformを用いたAWSリソースの管理
5. Packerを用いたAMI作成
6. 稼働中サーバのセキュリティアップデート
7. メトリクスグラフの取得&slackへの投稿

などにCircleCIを利用しており、今回はその中のインフラCIと稼働中サーバへのプロビジョニング 部分を入門用に噛み砕いて書いてます。

Kaizen Platform, Inc.におけるインフラの継続的デリバリー、インテグレーションについては技術顧問である伊藤直也さんのブログ、@m_doiの昨年JAWS発表資料を合わせて見ていただくと理解が深まるかと思います。

• インフラの継続的デリバリー - naoyaのはてなダイアリー

既存環境に組み込みやすいように

本特集では下記のサービス、ツールを利用しています。

特集内でも説明をしていますがそれぞれを疎な状態を保つように利用しているので、組み替えやすく、別のサービス、ツールを利用していても取り入れやすいのでは無いかと思います。

HashiCorp tools

今回VagrantとTerraformを利用し、ローカルでのテスト環境、インフラCIを実現しています。Vagrantはすでに定番ツールとなっておりますが、Terraformについてはまだまだの印象がありますので、インフラCI用の使い捨てVM管理を通じ、Terraformの感触を掴んでいただければ幸いです。

目次

それぞれの特集が独立しており、好きなところから読んで、手を動かして試せる内容となっています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

巻頭企画 DevOpsとInfrastructure as Codeの概要
吉羽 龍太郎
第1章 DevOpsとは?
第2章 Infrastructure as Codeとは?

特集1 最速攻略!Ansible 2によるサーバ構築
新原 雅司
第1章 Ansibleの基本
第2章 Playbookの基本
第3章 Ansible[実践]
第4章 Playbookベストプラクティス

特集2 CircleCIによる継続的インテグレーション入門
前田 章
第1章 インフラのテスト入門
第2章 ローカル上でのテスト駆動インフラ
第3章 インフラCIの準備
第4章 CircleCIを利用した継続的インテグレーション
第5章 継続的インテグレーションから継続的デリバリーへ

特集3 Dockerによる仮想環境構築とKubernetesによるDockerクラスタ管理
馬場俊彰
第1章 Dockerの基本
第2章 Dockerを使ってみよう[基礎編]
第3章 Dockerを使ってみよう[応用編]
第4章 クラスタ管理ツールとは
第5章 Kubernetesの基本
第6章 Kubernetesクイックスタート
第7章 Kubernetesを詳しく見てみよう

正誤表

TerraformのDownload URLが発売直前のこのタイミングで変更になってしまい(泣)、一部コードがそのままでは動かなくなっております。詳しくは技術評論社様のサイトでご確認ください

• http://gihyo.jp/book/2016/978-4-7741-7993-3/support

最後に

担当した特集で利用しているServerspecの作者であるmizzyさんの紹介で特集が実現し感謝です。 担当した特集部分のレビューにご協力頂いた @tnmtさん、@kenjiskywalkerさん、@satoryuさん、ありがとうございました。

余談ですが今回の執筆にあたり、CircleCIにいろいろと問い合わせをしていたところステッカーとTシャツが送られてきて、CircleCIにも感謝です! / Thanks CircleCI !!

A photo posted by Akira Maeda (@glidenote) on Jan 21, 2016 at 4:59am PST

本書がビジネスに貢献するITインフラの役に立つ1冊になれば幸いです。

追記 2月26日追記

本日2016年2月26日(金)発売で、今現在カテゴリー別1位になっているようで、ありがとうございます!

技術評論社様、特別企画「継続的Webサービス改善」執筆陣のGMOペパボのみなさんからご恵贈いただきましてありがとうございます。

『WEB+DB PRESS』の掲載記事をテーマ別に厳選、再編集とのことで、LINE、ドラゴンクエストX、freeeの事例などは 2015年のものが掲載されており、その他は2013年と3年前の事例なので多少古さがあるが、現在でも有益な情報には変わりない感じ。

LINE、ドラゴンクエストX、DMM.com などの大規模トラフィックを関する知見が参考になるのはもちろんですが、 特にGMOペパボの特別企画「継続的Webサービス改善ガイド ── 複雑性の増大と環境の変化に対応する」に関しては、 2013年当時私も在職しており、10年続くサービスをいかに改善していくかということに取り組み始めた頃で、 それから約3年経過し、最近のGMOペパボのエンジニアの勉強会での発表資料を見ると、 この本に書かれている通りに、その後サービス改善に取り組んでいることがよくわかって素晴らしい。

特にDB周りは鬼門だったので、それに関する発表資料を見ると、技術力の高さを感じる。

• MySQL 4.0で9年動き続けたサーバを リプレイスしてバージョンアップした話
• Mysqlを4.0から5.0を経由して5.6へバージョンアップした話

ほとんどのWEBサービスが10年も続かずにサービスを終了してしまうのを考えると、 長年続いているサービスの改善に関するGMOペパボの取り組み、知見は非常に希少度が高いし、 その元となっている考え方の基礎となっている部分が書かれており、2016年も必読の内容かと思います。

p.165のコードレビューの画像は、確か私のコードに対する指摘だなーと思い出して懐かさと汗が。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

■特集1:LINE ── 1日100億メッセージをさばくサービスの裏側
・第1章:LINEの歴史と開発体制
・第2章:LINEのサーバサイドアーキテクチャ
・第3章:LINEのメッセージング基盤
・第4章:LINEのストレージ
・第5章:スタンプショップの舞台裏

■特集2:ドラゴンクエストX ── 国民的RPGオンライン化へのチャレンジ
・第1章:ドラゴンクエストXとは何か
・第2章:開発・運営体制
・第3章:開発の舞台裏
・第4章:サーバプロセス構成
・第5章:1つの世界

■特集3:クラウド会計ソフトfreee ── 急成長を支えたコードとプロセスの改善
・第1章:クラウド会計ソフトfreeeの全体像
・第2章:急成長するシステムの課題と処方箋
・第3章:フロントエンド開発の複雑化への取り組み
・第4章:規模の拡大に伴う開発プロセスの変遷
・After That:freeeの現在

■特集4:DMM.com ── 動画配信に耐えるインフラ、好機を逃さない高速開発
・第1章:システムの全体像
・第2章:変化しつづけるインフラ
・第3章:負荷対策とパフォーマンス改善
・第4章:動画配信の裏側
・第5章:好機を逃さない高速開発
・第6章:多様なサービスはいかに作られるか
・After That:DMM.comの現在

■特別企画:継続的Webサービス改善ガイド ── 複雑性の増大と環境の変化に対応する
・第1章:なぜ「継続的Webサービス改善」が必要なのか
・第2章:開発環境の改善
・第3章:パフォーマンスの改善
・第4章:インフラ構成管理の改善
・第5章:ビジネス視点の改善
・第6章:これからも続く「改善」へのとりくみ

■一般記事:社内の情報共有・情報発信 ── クックパッドはいかにして場を築いたか

• Roost Laptop Stand: Portable, Lightweight, Adjustable, Ergonomic Stand

Kickstarterで注文していた新しいRoost Laptop Standが昨年末に届いて、最近は下のような形で作業している。

2016年に向けた作業環境が整った

A photo posted by Akira Maeda (@glidenote) on Dec 28, 2015 at 1:17am PST

1ヶ月半くらい、この状態で過ごしてみての感想は、

• 真っ直ぐを向く姿勢になるので、肩こりが解消した
• 姿勢が楽なので集中力が長時間持続する
• イヤホンを接続するとケーブルが邪魔
• Roostは持ち運びを想定した設計だが、キーボードとかも一緒に持ち歩かないといけないので、持ち運びには適さない(と思う)

単に目の高さにディスプレイがくるようになれば良いのかと思って、それまで使っていた外部ディスプレイ(27インチ)を目線の高さにくるようにしてみたけど 外部ディスプレイだと画面が広いせいか、首は動かないけど視線(眼球)がよく動いて、目の疲れは軽減されないことがわかった。

MacBook Pro Retina 15くらいだと視線ほぼ動かないので、目が疲れず、それが肩こり軽減にも一役買っている。

これまで肩こりで集中力が切れることが結構あったが、Roostを使いだしてからそれが無くなって劇的に快適になった。 作業環境において、ここ数年で一番良い買い物をした感じがする。

参考

• Rebuild: Aftershow 71: Green Grass On GitHub (Naoya Ito)

去年アメリカに行ったタイミングから完全にブログ書く習慣がなくなってしまったので、リハビリも兼ねて。

• Let’s Encrypt - Free SSL/TLS Certificates

前提

• Port 80が空いている。外部からアクセスできる。
• DNSが引けて、名前解決ができるようになっている

作業環境

• CentOS 7.0, Amazon Linux
• Nginx 1.9.10

Let’s Encryptのインストール

1
2
3

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt/
./letsencrypt-auto --help --debug

./letsencrypt-auto --help --debug のタイミングで依存パッケージがインストールされる。 無事インストールが完了するとヘルプが表示される。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Updating letsencrypt and virtual environment dependencies......
Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt --help

  letsencrypt-auto [SUBCOMMAND] [options] [-d domain] [-d domain] ...

The Let's Encrypt agent can obtain and install HTTPS/TLS/SSL certificates.  By
default, it will attempt to use a webserver both for obtaining and installing
the cert. Major SUBCOMMANDS are:

  (default) run        Obtain & install a cert in your current webserver
  certonly             Obtain cert, but do not install it (aka "auth")
  install              Install a previously obtained cert in a server
  revoke               Revoke a previously obtained certificate
  rollback             Rollback server configuration changes made during install
  config_changes       Show changes made to server config during installation
  plugins              Display information about installed plugins

Choice of server plugins for obtaining and installing cert:

  --apache          Use the Apache plugin for authentication & installation
  --standalone      Run a standalone webserver for authentication
  (nginx support is experimental, buggy, and not installed by default)
  --webroot         Place files in a server's webroot folder for authentication

OR use different plugins to obtain (authenticate) the cert and then install it:

  --authenticator standalone --installer apache

More detailed help:

  -h, --help [topic]    print this message, or detailed help on a topic;
                        the available topics are:

   all, automation, paths, security, testing, or any of the subcommands or
   plugins (certonly, install, nginx, apache, standalone, webroot, etc)

証明書を作る際に、letsencryptが80番を利用するので、nginxを一時的に落とす

1

sudo service nginx stop

下記コマンドを実行して証明書を作成する。

1

./letsencrypt-auto certonly --standalone -d webapp.glidenote.com

キー紛失時の復元用のメールアドレスを入力

規約の同意画面

完了すると下記のようにメッセージが表示される。証明書の期限は90日。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to xxxxxx@xxxxxxxxxxxxxxxx.
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/webapp.glidenote.com/fullchain.pem. Your cert
   will expire on 2016-05-02. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - Your account credentials have been saved in your Let's Encrypt
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Let's
   Encrypt so making regular backups of this folder is ideal.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

下記のような感じでファイルが出来上がる。

1
2
3
4

/etc/letsencrypt/live/webapp.glidenote.com/fullchain.pem
/etc/letsencrypt/live/webapp.glidenote.com/cert.pem
/etc/letsencrypt/live/webapp.glidenote.com/chain.pem
/etc/letsencrypt/live/webapp.glidenote.com/privkey.pem

nginxで利用するのは fullchain.pem と privkey.pem なので、nginxのconfを修正。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

server {
  listen 443 ssl http2;

  server_name         webapp.glidenote.com;

  ssl_certificate     /etc/letsencrypt/live/webapp.glidenote.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/webapp.glidenote.com/privkey.pem;

  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;


~ snip ~~

}

nginxを起動させてみる。

1
2

sudo nginx -t
sudo service nginx start

ちゃんとエラーが出ない証明書が出来上がっている。

更新については公式ドキュメントにあるように、下記のようのあスクリプトを用意してcronで回しておけばOKの模様。(検証用途でしか利用していないので、更新作業はまだやってないです)

1
2
3
4
5
6
7
8

#!/bin/sh
service nginx stop  # or whatever your webserver is
if ! /path/to/letsencrypt-auto certonly -tvv --standalone --keep -d webapp.glidenote.com > /var/log/letsencrypt/renew.log 2>&1 ; then
    echo Automated renewal failed:
    cat /var/log/letsencrypt/renew.log
    exit 1
fi
service nginx start # or whatever your webserver is

参考

• Let’s Encrypt の使い方 - Let’s Encrypt 総合ポータル
• Let’s EncryptとnginxでHTTP/2サーバを立てる - pixiv inside

• Nightmare

TL;DR

• Slack + Hubot + Nightmare + CircleCI を利用してSlackにNewRelicのメトリクスグラフやBIレポートを投げるようにした
• Slackなどチャットツールとのintegrationが無いツールでもグラフを投稿出来るようにした
• 会社のKPIやサービスの状態をSlack上からhubotを利用して誰でも簡単に確認が出来るようになった

仕組み

1. Slack上でHubotを呼び出す(hubot-cronで自動で稼働する)
2. HubotがCircleCIのAPIを叩いて、rebuid
3. CircleCI上でNightmareを利用し、NewRelicやBIツールのスクリーンショットを取得し、s3にアップロード
4. SlackのIncoming webhooksを利用してグラフを投稿する

NewRelicにログインしてスクリーンショットを取るスクリプトサンプル

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

var Nightmare = require('nightmare');
var fs = require('fs');

var urls = [];
urls.push('https://rpm.newrelic.com/accounts/xxxxxxxxxxxxxxxxxxxxxxxxxxx');
urls.push('https://rpm.newrelic.com/accounts/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx');
urls.push('https://rpm.newrelic.com/accounts/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx');

var i = 0;

for(u in urls) {
    var url = urls[u];
    var filename = '/tmp/tmp' + i + '.png';
    fs.appendFile('/tmp/urls.txt',url+'\n');
    new Nightmare()
      .viewport(1600, 900)
      .useragent("Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36")
      .goto('https://login.newrelic.com/login')
      .type('#login_email', 'foobar@sample.com')
      .type('#login_password', 'foobarpass')
      .click('#login_submit')
      .wait()
      .goto("https://rpm.newrelic.com/set_time_window?tw%5Bdur%5D=last_3_days")
      .goto(url)
      .wait(10000)
      .screenshot(filename)
      .run(function (err, nightmare) {
        if (err) return console.log(err);
        console.log('Done!');
     });
    i = i + 1;
}

circle.yml

• CircleCI上のphantomjsが古くグラフが正常に表示されないので、2.0.1にバージョンアップしてます。
• ブランチ毎で処理を変更
• スクリーンショットをs3にアップロードして、slackにpostするスクリプトはいろいろとハードコードされているので割愛…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

dependencies:
  pre:
    - bundle install
    - npm install
    - sudo apt-get update; sudo apt-get install libicu52
    - curl --output /home/ubuntu/bin/phantomjs-2.0.1-linux-x86_64-dynamic https://s3.amazonaws.com/circle-support-bucket/phantomjs/phantomjs-2.0.1-linux-x86_64-dynamic
    - chmod a+x /home/ubuntu/bin/phantomjs-2.0.1-linux-x86_64-dynamic
    - sudo ln -s --force /home/ubuntu/bin/phantomjs-2.0.1-linux-x86_64-dynamic /usr/local/bin/phantomjs

test:
  pre:
    - phantomjs --version
    - npm test

deployment:
  master:
    branch: master
    commands:
      - node ./scripts/foobar.js
      - ./bin/post_image_to_slack -c \#bot-test -t "post title" -u "kaizenbot"

  newrelic-webapp-overview:
    branch: newrelic/webapp-overview
    commands:
      - node ./scripts/newrelic-webapp-overview.js
      - ./bin/post_image_to_slack -c \#engineering -t "New Relic Webapp Overview" -u "New Relic Report Bot"

  newrelic-external-services:
    branch: newrelic/external-services
    commands:
      - node ./scripts/newrelic-external-services.js
      - ./bin/post_image_to_slack -c \#engineering -t "New Relic External Services" -u "New Relic Report Bot"

  domo-variations:
    branch: domo/variations
    commands:
      - node ./scripts/domo-variations.js
      - ./bin/post_image_to_slack -c \#general -t "K2 & BP Variations" -u "BI Report Bot"

実際の動作

• 実際にはhubot-cronを用いて自動で動くようになっています。
• BIレポートは日替わりで内容を変えるようにしてます。
• hubotを利用して、誰でも任意のタイミングで実行出来るようにしてます。

参考

• New Relic のグラフを毎時チャットに貼り付ける - @kyanny’s blog
• NightmareでE2Eテストしつつスクリーンショットとってgifに結合したら目視チェックが最高に楽になった - Qiita
• nightmare.jsとgmを使ってnode.jsでLIGブログの更新をSlackでゲットだぜ | 株式会社LIG
• Circleci上でPhantomjsを使ってReactアプリをテストする

私が悪戦苦闘しているのを横目に、技術顧問が寿司情報を収集するのにサラッと使いこなしていた有益プレゼン死霊

TL;DR

• Kaizen Platform, Inc.で利用しているCDNをAkamaiに切り替えた
• Akamaiはスタートアップでも利用出来るコスト感
• 高可用性構成のAkamaiを利用することでCDNの可用性というインフラエンジニア的に頭の痛い問題が減った

CDN第一世代 AWS CloudFront CDN (-2015年1月)

• CDNにCloudFrontを利用

サービスで利用しているインフラのほとんどがAWSで稼働しており、 その関係でCDNもCloudFrontを選択。

CDN第二世代 CloudFront + CDN77 (2015年1月-5月)

• AWS CloudFrontにおいて、2014年11月、12月と立て続けに障害が発生し、 CloudFrontの障害がサービス提供に与える影響が大きいため、対策を実施。
• Route53のDNSフェイルオーバーとCloudFront + CDN77を利用し、CDNを冗長構成

対策を講じるにあたりヌーラボさんの下記のブログが大変参考になった。

• 実践！ヌーラボサービスでの CloudFront の障害対策 - ヌーラボ [Nulab Inc.]

ヌーラボさんの記事を参考に予備系CDNの調査と選定

当時のCDNの必須要件

• 専用 IP 独自 (SSL Dedicated IP Custom SSL) が利用出来る。
• Amazon S3をバックエンドに利用出来る
• 日本とUSにエッジがある
• 予備系なので従量課金が良い
• AWSとは別の独自ネットワーク上に構成されている

当時6社くらいのCDN検証と問い合わせを行い、上記条件を満たすCDNとしてCDN77.comが最適だったので、 Route53のDNSフェイルオーバーとCloudFront + CDN77を利用し、CDNを冗長構成にした。(ヌーラボさんで利用していたKeyCDNは当時調査していたときSNI Custom SSLしか提供しておらず要件を満たさず)。 余談ですがCDN77は結構込み入った技術的な質問にも1時間以内で返信してきて、 サポート体制が素晴らしかったのも選定要因になりました。

CDNの冗長構成を構築したんですが、幸か不幸か、CloudFrontに障害が発生しなかったため、 予備系のCDN77が稼働することは無かった。

CDN第三世代 Akamai(2015年6月-)

• CDNにAkamaiを利用
• AkamaiはSLA100%なので利用することはないと思いますが高可用性構成のため利用することはほぼ無さそうですが、予備系としてそれまで稼働していたCloudFrontを残す(追記 2015年8月18日 誤解を招く表現なので修正しました)

CloudFront + CND77の冗長構成の懸念点

• 検証としてCloudFrontをDisableにしたときには自動でCDN切り替わったが、CloudFrontが実際に障害になったときの挙動が検証不可のため、自動で切り替わるか確認出来ず
  • Route53のDNSフェイルオーバーに10〜20分程度要する(CloudFrontが完全に反応無くなるまでコンテンツが返ってくるためフェイルオーバーが実行されない)
• CloudFrontの障害発生頻度として、年に1〜2回程度なので、そこで正常に冗長構成が稼働するか不安がある

Akamaiを選択した理由

• 高可用性構成
• 私を含めインフラのメンバー全員前職などでAkamaiを利用していたので、特徴などを把握している
• 数年間Akamaiを利用した経験の中で障害無し
• 担当営業の方の頑張り＆ボリュームディスカウントがあり、スタートアップでも利用できる、財布に優しいコスト感

Akamai With ChatOps

ngs/hubot-cloudfront で、SlackからCloudFrontのInvalidateを実行していた部分を hubot-akamai-ccu を導入し、 SlackからAkamaiのキャッシュのInvalidateを実行出来るようにもした。

この手の話はあまり外に出すような話じゃないかと思うんですが、 Kaizen Platform, Inc.のエンジニア行動指針というのが、社内Qiita Teamにあって、 冒頭にCEO @sudokenのmessageが載っていて、 その中に

様々な国や地域で多くの人が前向きに協力したくなるようなオープンな組織や事業でいよう

というのがあり、この情報が役に立つ人達もいると思うので公開しました。 CDNの可用性はインフラエンジニア的にかなり頭の痛い問題だと思いますし、 参考になれば幸いです。

先日Hashicorp Product Meetupに 参加したときに、KAIZENのエンジニア行動指針を見たいとの意見を頂いたので、 その他の行動指針を一部公開すると下記のような感じになってます。

発売日に買っていたんですが、多忙で感想を書くのを忘れていた。。

前職では業務でAWSをほぼ触らず、6年弱ずっとオンプレミス環境でインフラエンジニアをやっていたので、 昨年KAIZENへの転職を機にはじめてAWSをガッツリ触るようになった。(個人レベルではもちろん触ってましたが)

AWSを実際に触ってみると

• 各サービスの特徴
• それぞれのサービスを組み合わせた構成例
• 各種設定方法

などについて、体系的に学べる書籍などが無く(あっても情報が古い)、 ウェブ上の断片的な情報をその都度参照して、 恐ろしく非効率な方法で習得して、苦労していたので、 本書は体系的にAWSのことが習得出来るので大変ありがたかった。

リファレンス的に利用出来るので、「この設定どうするんだろう」みたいな時に 役に立ってくれている。

紙書籍は450ページもあり、ちょっと持ち歩くのがツラそうだったので、 Kindle版を購入したんですが、ページが画像として処理されているので、 ページ送りが非常に遅く、また文字検索が出来ないのがちょっと残念な感じだったけど 非常にわかりやすく、内容的にはすばらしかった。

AWSはサービス開発のスピードが速く、新機能が増えたり、UIが変わったりと 変化が激しいので、1〜2年後には訳に立たなくなってしまうかもしれないが、 現時点(2015年5月)でAWSに関しての体系的な知識を習得するのにはオススメだと思う。

本書目次

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

Chapter1 AWSの基本
1-1 AWSとは
クラウドとは
物理サーバ(オンプレミス)とAWSの違い
レンタルサーバ(共有サーバ)とAWSの違い
プライベートクラウドとAWS
AWSのサービス全体像
1-2 AWSのネットワークサービス
リージョンとアベイラビリティゾーン
Virtual Private Cloud (VPC)
Route53
AWSネットワークとVPCネットワーク
1-3 コンピュータ基盤としてのAWS
Amazon Elastic Compute Cloud(EC2)
Amazon Elastic Block Store(EBS)
EC2におけるバックアップ
Amazon Simple Storage Service(Amazon S3)
Amazon Glacier
1-4 アプリケーション基盤としてのAWS
Relational Database Service(RDS)
Elastic Beanstalk
ElastiCache
1-5 サービスとしてのAWS
AWSのアプリケーションサービスの概念
SESとSQS
SNSとCloudWatch
1-6 AWS利用のコスト
AWSの料金体系
AWSの料金計算の仕方
Chapter2 AWSを利用する
2-1 AWS利用の準備
AWSアカウントの作成
ユーザアカウントの作成(IAM)
2-2 AWS CLI
AWS CLIのインストールと設定
AWS CLIの基本的な使用方法
2-3 AWS SDK
サポートされる言語とバージョン
AWS SDKのインストールと設定
AWS SDKの基本的な使用方法
2-4 VPCネットワークの作成
Default-VPC
Custom-VPCを作成する
2-5 仮想コンピュータ(Amazon EC2)の利用
AWS操作用の公開鍵・秘密鍵の作成(KeyPair)
Security Groupを作成する
EC2を起動する
AMIを作成する
ElasticIP(EIP)の利用
2-6 ELB(Elastic Load Balancer)を使用する
ELBのサービス詳細
ELBの作成
Chapter3 パターン別構築例
3-1 EC2を利用した動的サイトの構築
WordPressを使ったブログサイトの構築
ロードバランシングとHTTPSサイトの構築
Marketplacesを利用して、構築済みのインスタンスを利用する
3-2 Elastic Beanstalkによる動的サイトのサーバレス構築
Elastic Beanstalkを利用した再構築
Elastic Beanstalkを利用したロードバランシングとHTTPSサイトの構築
3-3 S3による静的サイトのサーバレス構築
S3による静的サイトの構築
Route53を利用してDNSを設定する
Route53へドメインの移管
CloudFrontとの連携
3-4 Auto Scalingによる自動スケーリングシステムの構築
Auto Scalingの設定
Auto Scalingを利用するためのアプリケーション構成
Auto Scaling使用時のEC2インスタンスの初期化処理
Immutable Infrastructure
3-5 Elastic BeanstalkとLambdaによるバッチサーバの構築
Elastic Beanstalkによるバッチサーバの冗長化構成
Lambdaによるサーバレスな処理システムの構築
3-6 CloudFormationによるテンプレートを利用した自動構築
CloudFormationの概要
CloudFormationによるネットワーク構築
CloudFormationによるサーバ構築
3-7 SESによるメール送信システムの構築
SESを使ってメールを送信する
EC2インスタンスにメールサーバを構築する
外部のメール送信サービスを利用する
3-8 AWS上に開発環境を構築する
開発環境の構築と運用
継続的インテグレーション(CI)を実施する
3-9 モバイルアプリからAWS上のリソースを利用する
Cognitoによるユーザ認証と2-tierアーキテクチャ
AWSのモバイル開発プラットフォーム
SNSによるモバイルプッシュ通知
Chapter4 AWSのセキュリティ
4-1 AWSのセキュリティへの取り組み
責任共有モデル
第三者認証
4-2 IAM(AWS Identity and Access Management)
AWSのアカウント種類
IAMユーザとIAMグループ
IAMロール
4-3 データ暗号化
AWSが提供するデータ暗号化サービス・機能
4-4 WAF・IDS・IPSによる外部からの攻撃対策
外部からの攻撃の種類と防御方法
エージェント型とリバースプロキシ型のサービス導入例
4-5 VPCでネットワークセキュリティを高める
VPCによるSubnet構成
SecurityGroupとNetworkACL
4-6 AWSと脆弱性診断
侵入(ペネトレーション)テスト
侵入(ペネトレーション)テストツール
Chapter5 管理と運用
5-1 ジョブ管理
ジョブ管理システムの概念
サービス型のジョブ管理システム
5-2 システムを監視する
AWSのなかから監視する
AWSの外から監視する
5-3 アラートを通知する
AWSの機能を利用した通知方法
Twilioを利用した電話通知
5-4 データをバックアップする
EBSのデータバックアップ
S3とGlacierを使ったバックアップと管理
AMIの運用方法
5-5 AWSにおけるログ管理
AWSのサービスログ/操作履歴のログを収集保存する
EC2インスタンスのログを収集保存する
5-6 AWSにおけるコスト管理
AWSにおけるコスト管理
AWSのコストを節約する
5-7 AWSの利用を支えるサポートの仕組み
AWSサポート
AWS Trusted Advisor

参考

• 『Amazon Web Services パターン別構築・運用ガイド』を書きました - プログラマになりたい
• 「Amazon Web Services パターン別構築・運用ガイド」の目次 - プログラマになりたい

• Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した
• 各ツールの役割は下記のような感じ
  • Terraform => インフラへの変更ツール
  • GitHub => .tfファイルのバージョン管理
  • CircleCI => CI、Terraformをawsに対して実行
  • Atlas => インフラの状態を記録するterraform.tfstateの管理
• インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した

背景

今までの問題点

• AWSの各種操作がブラウザからポチポチ業…
• 手作業なので誤操作に気づきにくい。事故りやすい
• インフラの実構成がバージョン管理出来ていない
• ちなみにRoute53に関してはroadworkerを用いてコードで管理済みなので、今回はRoute53以外の話です。
  • refs インフラの継続的デリバリー - naoyaのはてなダイアリー

Terraform + GitHub + CircleCI + Atlas でインフラを管理するメリット

• ブラウザからのポチポチ業から解放される
• インフラ構成をコードで管理出来る。バージョン管理が出来る
• インスタンス追加、EIPの設定などAWSの操作、インフラ構成の変更をGitHubのPR、レビュー、Mergeのプロセスに載せることが出来る
• 自動化が可能になる
• CircleCI上にインフラ変更のログを保持することが出来る
• インフラの変更をGitHubのMergeボタンに集約出来る

実装概要

2015年2月18日現在最新のTerraform v0.3.6を用いて実現している

1. EC2、EIPなどAWSの変更をコードに書いてGitHubにPush。(Atlasでterraform.tfstateを管理している場合はterraform pullして最新のterraform.tfstateもPush)
2. Pushを契機にCircleCI上でterraform plan --refresh=falseを実行してtest。testが通ればPull Requestを作成
3. Pull RequestをmasterにMerge
4. masterへのMergeを契機にCircleCI上からterraformを実行
5. terraform applyを実行して、awsに設定を反映
6. Atlasにterraform pushして、terraform.tfstateファイルを管理
7. 鮨を食べる

CircleCI上からterraformを実行しているキャプチャ

設定ミスやエラーが発生するとFailしてSlackに通知される

実際のtfファイルの感じ

• Provider: AWS - Terraform by HashiCorp

クレデンシャル情報はCircleCI上で暗号化した環境変数を管理していて、Gitリポジトリ内では管理せず、 CI実行時に生成している。

1
2
3
4
5
6
7
8
9
10

# credential
provider "aws" {
    access_key    = "XXXXXXXXXXXXXXXXXXXX"
    secret_key    = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    region        = "us-west-1"
}

provider "atlas" {
    token         = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# instance
resource "aws_instance" "dev001_foobar_net" {
    ami             = "ami-xxxxxxxx"
    instance_type   = "t2.micro"
    key_name        = "xxxxxxxxxxxxxxxx"
    security_groups = ["sg-xxxxxxxx"]
    subnet_id       = "subnet-xxxxxxxx"
    tags {
        Name    = "dev001.foobar.net"
        Role    = "common"
        Service = "operator"
        Env     = "dev"
    }
}

1
2
3
4
5

# eip
resource "aws_eip" "dev001_foobar_net_eip" {
    instance = "i-xxxxxxxx"
    vpc      = true
}

などTerraformは同じディレクトリ内にある.tfファイルを見てくれるので、 用途毎で.tfファイルを分けて運用してます。

その他

• 2014年8月にTerraformがリリース直後にチャレンジしたが、機能が足りずに実現出来なかったが、半年経過して必要機能が揃い実現出来た。
• 今日現在(2015年2月18日)TerraformにはAWS上の既存設定をファイルに落とし込む機能がないので、一から作る必要がある。
• 今回はインスタンスの一斉リプレイスがあったので、そのタイミングを利用して導入した。
• AtlasとGitHubの連携機能がリリース予定なので、それがリリースされるとさらに便利になるかもしれない(1月リリース予定だったけど)
  • Using Atlas with GitHub
• 今回はAtlasとTerraformだけを組み合わせたが、AtlasはVagrant、Packer、Consulとも連携が出来るので引き続き検証中

参考

• Terraform簡易チュートリアル on AWS - Qiita
• AWS Advent Calendar 2014 〜 Elastic IP アドレス (EIP) のお話 | cloudpack技術情報サイト

Serverspecを執筆されたmizzyさんからご恵贈頂きました。ありがとうございます。

本書の詳細な紹介はあんちぽさんのブログと、mizzyさんが出演したRebuildがオススメです。

• Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - delirious thoughts
• Rebuild: 75: Book Driven Development (gosukenator)

事前に断っておくと私がここで記載している「インフラエンジニア」はITインフラエンジニアの話です。

以前サーバ/インフラ徹底攻略を本ブログで紹介したあとに、 書内のある特集を執筆担当された方と話していて、

Web系インフラエンジニアがどんどん先鋭化されつつあって、この本の内容を理解出来る人ってどれくらいいるんだろうね

という事を仰っていたのが非常に印象的であった。

先鋭化という言葉を聞いて、昨今のWebインフラエンジニア界隈の技術を思い起こすと、 Serverspecの登場以前、以後でその先鋭化具合が顕著になったと個人的に思っている。

サーバのテスト標準ツールとなったServerspec

ServerspecはWeb系インフラエンジニアに待望されていたものであり、 その登場により現在のサーバ構築において

1. PuppetやChefなどでインフラのコードを書く
2. 適用する
3. Serverspecでテストを実行する

という一連の作業がスタンダードになった。

サーバ構築の一連の作業において一番面倒な確認作業をコードに出来ることで、 自動化、属人性の排除、CIはもちろん、何が設定されていて、何が動いているのかなどインフラの透明性を高める事が可能になった。

またserverspec/serverspecのcontributorsを見ると、 Web系インフラエンジニアが非常に多いことから分かるように、作者のmizzyさんを中心に、 Web系インフラエンジニアが自分たちで使うためにPRを送り、それが取り込まれ機能拡張され進化したツールだと思っている。

Kaizen Platform, Inc.でのServerspec利用

私の現在勤めるKaizen Platform, Inc.においても、技術顧問であり本書の前書きを担当した伊藤直也さんによって Serverspecは導入され、インフラエンジニアのyoshiakisudo、@m_doiによりChef + Serverspec + GitHub + CircleCI + Docker を組み合わせる形に進化し、

1. Chefのレシピを書く。Serverspecのテストを書く
2. GitHubにPushする
3. GitHubへのPushを契機にCircleCI上に新規にDockerコンテナを立て、Chefを適用
4. DockerコンテナにServerspecを流してテストを実行する

というサイクルを1日に十数回まわして、インフラの継続的な改善を行っている。

サーバへのChef適用

余談であるが、サーバへのChef適用は@m_doiのより昨年夏からChatOps化されており、

チャット(Slack)上からhubot経由でGitHub上にデプロイ用PRを作成

作成されたPRのmerge

mergeを契機にCircleCI経由でサーバにChefを適用

というようになっていて、手元やサーバからコマンドラインを操作して実行することはない。

これが可能なのもServerspecにより、インフラコードのテストが行われているためであり、Serverspecの功績は非常に大きい。

Serverspec本を読むことは、Serverspecという強力な武器を手にして、飛躍的に進化し続けているWeb系インフラエンジニアを知るために 最も有用な手段である。

最近1週間くらいずっとAmazonでベストセラー1位になっているので、もう既にみんな読んでいると思いますが傑作です。

本書内で拙作の

• glidenote/serverspec-snippets
• vim-quickrunでServerspecをカーソル行単位でテストして編集効率を10倍にする - Glide Note - グライドノート

を紹介して頂いて、期せずしてオライリー本デビューをさせていただきました。ありがとうございます

モニタリング領域

サービスを監視している領域

Pingdom

• Pingdom - Website Monitoring
• 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。
• 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている

Sensu

• Sensu | The open source monitoring framework.
• 監視フレームワーク
• サーバを内部ネットワークから監視するために利用
• サーバのプロセス監視、サーバ間の疎通監視、エラー監視など一般的な監視はSensuが担当
• 自作の監視プラグインなども利用して監視

Mackerel

• Mackerel: A Revolutionary New Kind of Application Performance Management
• メトリクス監視。
• CPU、メモリ、LA監視などグラフと一緒に確認したいものはMackerelが担当
• CPUアラートが来たら、Mackerelの画面を見て、いつから現象が発生しているかなどすぐに確認が出来る。

Incident Management領域

アラート通知先や障害情報の自動更新を管理している領域

StatusPage.io

• StatusPage.io - Hosted Status Pages for Your Company
• サービスのステータスを外部に公開、障害情報の公開に利用。 Kaizen Platform Inc Status
• Pingdomと連携しているので、サービスに障害があった場合は自動でお知らせが出る。
• Twitter連携しているので障害情報を公開すると、Twitterアカウントにもお知らせが出せる。

PagerDuty

• Incident Management System for IT Monitoring Tools | PagerDuty
• アラートのハンドリングに利用
• 各監視サービスのアラートは全てPagerDutyに集約
• アラートの通知先をSMS、電話、スマホアプリ、チャットなどに設定出来る。
• 通知スケジュールも細かく設定出来るので、日替わりでエスカレーション先のエンジニアを切り替えている
• スマホアプリの出来が良い。

Infomation / Escalation領域

お知らせ、エスカレーション領域

Twitter

• 前述のstatuspage.ioと連携。
• statuspage.io上で障害情報を掲載するとTwitterにも投稿されるので、障害情報の更新において二度手間が無い。

Slack

• Slack: Be less busy
• 各種アラートがPagerDuty経由でSlackに通知される
• Slackに逐一通知されるんので、アラートの履歴や対応状況などが一目で分かるようになっている

電話、SMS、メール、アプリへのPush通知など

• PagerDutyが通知をハンドリングしてくれるので、「最初はSMSにアラートを送って、反応が無ければ○○分後電話する」など通知設定をして運用している。
• 監視担当の人がその日都合が悪かったりした場合など、通知先の変更が簡単にできる。

その他

• Mackerelの部分には、Datadogも検証。非常に素晴らしいサービスだった。
• 現時点ではDatadogの方が高機能なんですが、MackerelがDatadogの超えてくれるのを期待してMackerelを採用

なぜ複数のサービスを組み合わせて監視しているかは技術顧問の伊藤直也さんのスライドを見ると分かるかと思います。

来年にはガラッと変わっているかもしれないけど、各コンポーネントがAPIで疎結合化されているのでアーキテクチャの変更も容易。

些細な障害、兆候も検知して見逃さないように、いろいろと試行錯誤を繰り返している。

送信側

3000ポートを転送に使う場合。

1

pv hogemoge.zip | nc -l 3000

受信側

1

nc foobar.com 3000 | pv > hogemoge.zip

ファイル転送中は下記みたいな感じで転送済みデータサイズ、転送速度、残り時間、プログレスバーなど進捗が確認出来る

簡易的な回線速度の測定にも使えるので、大変便利。

参考

• nc(netcat)で超簡易ファイル転送 - うまいぼうblog
• プログレスバーを簡単に表示できるコマンド pv - apatheia.info
• Netcat – a couple of useful examples | G-Loaded Journal

• Amazon CloudFrontのアクセスログをBigQueryに入れるようにした
• BigQueryへのデータ投入には社内の他プロジェクトでも利用していて実績があり、KAIZENがメンテナになっているfluent-plugin-bigqueryを利用

背景

ここ2ヶ月くらい、あらゆるログをBigQueryに集約しつつあって、今回はAmazon CloudFrontのアクセスログについて作業をした。

Amazon CloudFrontのアクセスログには以下のような特徴がある。

• Amazon CloudFrontのアクセスログは数時間〜1日程度遅れでS3のBucketに追加される。時系列はバラバラ
• CloudFrontのアクセスログがtsv形式。
• ベストエフォート型で全てのログがS3に収容される保証は無い
• gzで圧縮されてS3に追加される(BigQueryに入れるにはgz形式から展開する必要がある)
• ログファイルの数が非常に多い。作業していた環境でだいたい1日に15,000個くらいgzファイルがあって、全部をダウンロードするのに160分くらいかかる

という感じ。

仕組みの詳細

データの流れ

1. CloudFrontのログが自動でS3に追加される
2. batchサーバからs3cmd syncでcronで定期的にs3からログファイル(gz形式)をローカルに持ってくる
3. batchサーバで、取得したログファイルをzcat ${FILE} >> /var/log/cloudfront/access.log で連結する
4. batchサーバのFluentdでin_tailを用い/var/log/cloudfront/access.logを読み込む
5. fluent-plugin-bigqueryを用いてBigQueryにデータを投入する(日付毎にデータ投入先のテーブルを分ける)

こんな感じでBigQueryにデータが入っている

先日発表されたS3 Event Notificasionsを検証中なので、問題が無ければ、Amazon SQSを利用した処理に切り替え予定。

この方式を採用した理由

• 私がFluentdの運用に慣れていた。
• KAIZENがメンテナをしているfluent-plugin-bigqueryを利用したかった
• BigQueryへのデータ投入部分を自前で実装しなくて良い
• BigQueryへのデータ投入周りのエラーハンドリング、再送処理をfluent-plugin-bigqueryに任すことが出来る
• logrotateを利用して、ログの世代管理が出来る。Fluentdがログ切り替えを検知出来る。(nginxのログなど他のアクセスログと同じような感じで扱える)
• Fluentdを利用しているので、スケールが容易
• /var/log/cloudfront/access.log-YYYYMMDD.gzというように日別でログが分かれているので、障害やトラブル発生時のリカバリーも簡単になっている。(障害が発生した日の15,000個とかのログをS3から持ってきて云々… みたいな面倒な処理が必要ない)

その他

• CloudFrontのログがS3に追加されるのが遅い場合1日程度かかるので、翌日のテーブルにデータが入ってしまう。BigQueryからデータを取り出すときに工夫が必要
• BigQueryにデータ投入先のテーブルが存在しないと死ぬので、別でテーブル作成の仕組みと監視をしておく必要あり。
• データサイズが大きい場合、テーブルを適切に分割していないとBigQuery破産に。
• テーブルの自動作成、監視にはbigqueryを利用

該当部分のtd-agent.confの設定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<source> 
  type         tail 
  path         /var/log/cloudfront/access.log
  pos_file     /var/log/td-agent/cloudfront-access-log.pos
  tag          extracted.cflog

  format       tsv
  keys         day,time,x_edge_location,sc_bytes,c_ip,cs_method,cs_Host,cs_uri_stem,sc_status,cs_Referer,cs_User_Agent,cs_uri_query,cs_Cookie,x_edge_result_type,x_edge_request_id,x_host_header,cs_protocol,cs_bytes,time_take
</source>

<match extracted.cflog>
  type                        bigquery

  buffer_type                 file
  buffer_path                 /var/log/td-agent/cf.bq.*.buffer

  method                      insert

  auth_method                 private_key
  email                       ''
  private_key_path            ''

  buffer_chunk_limit          768k
  buffer_queue_limit          5000
  flush_interval              1
  try_flush_interval          0.05 
  num_threads                 10 
  queued_chunk_flush_interval 0.01

  project                     ''
  dataset                     ''
  table                       %Y%m%d

  fetch_schema                true
</match>

BigQueryにログを集約したことで集計も調査も非常に簡単になって、本当にBigQuery素晴らしい。

S3 => SNS => SQS への通知は解説しているサイトが結構あるんですが、S3 => SQS への通知設定の 情報が見当たらなかったので、動くようになるまで、いろいろと試行錯誤を繰り返した。 特にSQSのPermission設定が恐ろしく分かりにくくに2日くらいハマったので、自分用にメモしておく。

S3 Bucketの作成

S3でBucketを作成。既存Bucketを利用する場合はここはSKIP。 今回は検証用にglidenote-sqs-testという名前でBucketを作成

SQSの設定

S3のイベント通知を受け取るQueueを作成する

Queue名をsqs-testをして作成。

Add a Permissionをクリックして通知の受信元を設定する。

下記のように設定して、Add Conditionを選択

• Valueにはarn:aws:s3:::{S3のBucket名}を設定

Actions部分はSendMessageだけ選択して、Add Permission を選択

こんな感じの設定になっていることを確認

S3 Event Notificationsの設定

S3のイベント通知をSQSに送るように設定。下記の例ではPUTとPOSTイベントのみSQSに通知するように設定

正しく設定が出来ると下記のようになる。SQSのパーミッション設定が上手くてきていないとエラーになる。

実際にS3 EventをSQSで受け取る

下記のようなrubyのスクリプトを用意してSQSでイベントを受信してみる

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/usr/bin/env ruby
# -*- coding: utf-8 -*-

require 'aws-sdk'

AWS.config(
  :access_key_id     => 'your_access_key_id',
  :secret_access_key => 'your_secret_access_key',
  :sss_endpoint      => 'sqs.ap-northeast-1.amazonaws.com'
)

url = 'https://sqs.ap-northeast-1.amazonaws.com/xxxxxxxxxxxx/sqs-test'

sqs = AWS::SQS.new

while true
  receive = sqs.queues[url].receive_message()
  if receive
    puts receive.body
    receive.delete
    sleep 1
  end
  puts "Waiting"
  sleep 1
end

するとほぼリアルタイムで下記のような感じでイベントを受信出来る

1

{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"ap-northeast-1","eventTime":"2014-11-20T06:16:39.474Z","eventName":"ObjectCreated:Put","userIdentity":{"principalId":"AWLW0VGTI46AA"},"requestParameters":{"sourceIPAddress":"10.115.144.24"},"responseElements":{"x-amz-request-id":"E1C0A0C1F42CAA54","x-amz-id-2":"0p2FzYuEkiyaZn/n33XJLYjE3cmePkiqEFF5NMYy+c1PSGTNfmUf+Msou4Mejnr0"},"s3":{"s3SchemaVersion":"1.0","configurationId":"S3TestNotification","bucket":{"name":"glidenote-sqs-test","ownerIdentity":{"principalId":"AWLW0VGTI46AA"},"arn":"arn:aws:s3:::glidenote-sqs-test"},"object":{"key":"shindel.png","size":794485,"eTag":"b52627268c0e9071be00c5a38fdbc912"}}}]}

リアルタイムでS3のイベントを受信するにはSQSと常時通信しているために Supervisordなどを用いてスクリプトを動かす必要があり。

これでリアルタイムな処理に対応が出来るようになった。ちょっと現在やってるタスクに適用出来るかしばらく検証してみる。

参考

• Amazon S3 Event Notifications
• バケットイベントの通知の設定 - Amazon Simple Storage Service