Glide Note

glidenote's blog

CDNをAkamaiに切り替えた

2ヶ月くらい前にCDNをAkamaiに切り替えたので、知見を公開。 (追記 2015年8月18日 私個人の認識不足で用語の使い方に問題があったので一部修正しました s/SLA 100%/高可用性構成/g)

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を冗長構成

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

ヌーラボさんの記事を参考に予備系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のエンジニア行動指針を見たいとの意見を頂いたので、 その他の行動指針を一部公開すると下記のような感じになってます。

「Amazon Web Services パターン別構築・運用ガイド」が良かった

Amazon Web Services パターン別構築・運用ガイド

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

前職では業務で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

参考

Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した

TL;DR

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

背景

今までの問題点

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ファイルの感じ

クレデンシャル情報は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月リリース予定だったけど)
  • 今回はAtlasとTerraformだけを組み合わせたが、AtlasはVagrant、Packer、Consulとも連携が出来るので引き続き検証中

参考

Serverspec本を読んで、先鋭化されつつあるWeb系インフラエンジニアを知る

Serverspec

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

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

事前に断っておくと私がここで記載している「インフラエンジニア」は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位になっているので、もう既にみんな読んでいると思いますが傑作です。

本書内で拙作の

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

監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版)

Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。

モニタリング領域

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

Pingdom

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

Sensu

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

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で疎結合化されているのでアーキテクチャの変更も容易。

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