1.
Wi
2015年4月21日
山田 直行
AWSからOpenStack,
Chef SoloからChef Serverに
インフラを置き換えた事例の紹介

2.
• 自己紹介
• ディスプレイ広告配信DSP「Smalgo」について
• AWSからOpenStackへ
• Chef SoloからChef Serverへ
• まとめ
目次

3.
• 山田 直行（やまだ なおゆき）
Twitter @satully
blog.kirishikistudios.com
• 株式会社サイバーエージェント アドテクスタジオ
Smalgoカンパニー ソフトウェアエンジニア
• アドネットワーク・DSPに携わって約3年
• 担当分野：インフラ・DevOps・サーバーサイドアプリケーション全般
• 好きなキーワード：自動化・大量トラフィック・イミュータブル
• AWS認定ソリューションアーキテクト アソシエイト（今日はここ重要）
• データの活用について、インフラ構築から分析、実サービスへの適用までを通
してできるエンジニアを目指しています
自己紹介

4.
• ディスプレイ広告（ バナー広告）の配信プラットフォーム
• 2014年5月から提供（前身となるプロダクトを含めると2014年2月から）
• スマートフォン向けがメインだが、PC向け配信も行っている
• RTBがメインだが、第三者配信など他の配信方法にも対応
• 成果報酬型課金が特徴
• 開発・運用メンバー計5.5人
• 30億Req/Day、トラフィックピーク時1.2GBpsくらい
ディスプレイ広告配信DSP「Smalgo」について
プロダクト概要

5.
ディスプレイ広告配信DSP「Smalgo」について
DSPの位置づけ
引用元：日本一やさしいアドテク教室 https://www.cyberagent.co.jp/ir/personal/adtech/adtech_05/

6.
AWSからOpenStackへ

7.
• AWSの東京リージョンで使っていたEC2部分を全て、社内チー
ムが構築・運用しているデータセンターのOpenStack(Nova)
ベースのシステムに移行した
• EC2+ELBのみ移行し、S3/Redshift/Route53/CloudFront
は引き続き利用。EMR/SESも引き続き少し利用している
• RDSやDynamoDBはもともと使っていなかった
（従来からEC2のMySQLとRedisを利用）
移行の概要

8.
• 費用削減のため(́・ω・`)
• 個人的にはAWSは決して高くないと思っているが、大きい会社だと一
括購入のメリットが大きかったり会計上の仕組みなどもあり、カンパ
ニー制なので独立採算の社内プロジェクトとしては移行したことで多大
な費用削減になった（このへんは各社事情が違うと思います）
• とはいえ、トラフィックやデータ量が多くてCPUもDiskIOも多く使う
システム特性上、EC2だと多少割高に感じていたのも事実
• また、広告配信システムとして1年間運用してきて、トラフィックの量
が見積もれるようになってきて、必ずしもEC2ほどのスケーラブルなイ
ンフラでなくても対応できるようになった
移行した理由

9.
• DirectConnectを使ってAWSとOpenStackをプライベートネットワークでつ
ないだ。しかし元のVPCはIP範囲の問題で直接つなげず、中間に踏み台となる
Direct Connect用VPCを置く必要があった
• 移行の瞬間にはバッチは数時間停止させ、配信サーバーは無停止で移行
移行手順
利用していたAWS VPC DirectConnect用AWS VPC 移行先のOpenStackネットワーク
DB DBHAProxy
App App
アプリサーバーは同じものを作成してDNS切り替え
DBサーバーはHAProxyを介してレプリケーションして移行の瞬間に切り替え
移行中のRead/Write

10.
• 基本的にはほとんど変わらないという印象
• ELBを使えないためアプライアンスのロードバランサに対応し
た設定にし、ELBでSSL Teaminationしていた部分をフロント
にnginxを置くようにしてnginxでhttpsも受けるように変更。
内部ELBを使っていた部分はHAProxyに置き換えた
• Amazon LinuxからCentOSにする際のパッケージの細かなバー
ジョン違いでつまづいた
• MySQL(5.5)からMariaDBにも移行したが特に問題なし
移行時のトラブル・気づいた点など

11.
Chef SoloからChef Serverへ

12.
• EC2時代はfabric + chef-soloという構成を取っていて、
fabricがbotoを通してEC2のInstanceおよびRoleの管理を行
うようにしていた
• 2年以上前に作った仕組みをベースにしているので、Knife-Solo
ですらなく、cookbookやroleのファイルを各サーバーにrsync
してfabricからchef-soloをキックするという実装
• これをChef Serverに置き換え、fabricでInstance管理をか
なりやっていた部分をChef Serverで一括管理するようにした
（作業進行中）
移行の概要

13.
• Chef Serverにツールを統一して社内インフラチームに管理を
任せられるようにするため
• Chef Serverのインタフェースを通してノードや設定を検索し
たり操作したりできるようにすることで、より動的で強固で
便利なインフラが作れそうな気がした（まだやってない）
移行した理由

14.
• Knifeコマンドやレシピ内でsearchができるのが非常に強力
移行してみて(1)
node.default["hosts"].merge!(
search(:node, "environment:#{node.environment}").reduce({}) do |hash, instance|
host = "#{instance.name.split("-").last} #{instance.name}"
hash.merge({ host => instance.ipaddress})
end
)
たとえばhostsを作るためにホスト名とIPアドレスのHashを作る
これまではAWSのAPIを使ったり、JSONでconfigを持ったりしていた。
これ以外にもクラスターに参加するノードを選んだり、レプリケー
ションすべきノードを自動で決定したりといろいろ考えられる

15.
• development/staging/productionでそれぞれ別の設定を使いたいときのベス
トプラクティスがまだ良くわからない
• Chef Soloのときはgitレポジトリに全ての設定があったので、環境ごとにブ
ランチやリビジョンを切り替えて開発していた
• Chef Serverになると、cookbookなどをアップロードすると全ての環境に
適用になってしまうので、environmentsでcookbookの（chef serverの）
バージョンを指定しているのだが、ここを更新ミスするとリリース漏れになっ
たり巻き戻ったりしてしまう
• RoleやDataBagsはバージョン指定できないので考え方を変える必要がある
• Chef Serverがノードの状態を保持していることを意識する必要がある
移行してみて(2)

16.
• 移行自体がスムーズにいったのはもともとAWSのコアなサー
ビスをあまり使っていなかったから。ロックインを避けたかっ
たのだが、AWSを使うならもっといろいろなサービスを組み
合わせて使うべきかもしれない
• Chef ServerはChef Soloの単なる上位互換という感じでもな
く、いくつか考え方を変える必要がありそう
• オンプレミスのサーバーにしたことで、深夜サーバーを自動で
止めたりオートスケーリングを考慮したりといったことが無く
なった
まとめ