awsからopenstack, chef soloからchef serverに インフラを置き換えた事例の紹介
TRANSCRIPT
Wi2015年4月21日 山田 直行
AWSからOpenStack, Chef SoloからChef Serverに インフラを置き換えた事例の紹介
• 自己紹介
• ディスプレイ広告配信DSP「Smalgo」について
• AWSからOpenStackへ
• Chef SoloからChef Serverへ
• まとめ
目次
• 山田 直行（やまだ なおゆき）Twitter @satullyblog.kirishikistudios.com
• 株式会社サイバーエージェント アドテクスタジオSmalgoカンパニー ソフトウェアエンジニア
• アドネットワーク・DSPに携わって約3年
• 担当分野：インフラ・DevOps・サーバーサイドアプリケーション全般
• 好きなキーワード：自動化・大量トラフィック・イミュータブル
• AWS認定ソリューションアーキテクト アソシエイト（今日はここ重要）
• データの活用について、インフラ構築から分析、実サービスへの適用までを通してできるエンジニアを目指しています
自己紹介
• ディスプレイ広告（≒バナー広告）の配信プラットフォーム
• 2014年5月から提供（前身となるプロダクトを含めると2014年2月から）
• スマートフォン向けがメインだが、PC向け配信も行っている
• RTBがメインだが、第三者配信など他の配信方法にも対応
• 成果報酬型課金が特徴
• 開発・運用メンバー計5.5人
• 30億Req/Day、トラフィックピーク時1.2GBpsくらい
ディスプレイ広告配信DSP「Smalgo」について プロダクト概要
ディスプレイ広告配信DSP「Smalgo」について DSPの位置づけ
引用元：日本一やさしいアドテク教室 https://www.cyberagent.co.jp/ir/personal/adtech/adtech_05/
AWSからOpenStackへ
• AWSの東京リージョンで使っていたEC2部分を全て、社内チームが構築・運用しているデータセンターのOpenStack(Nova)ベースのシステムに移行した
• EC2+ELBのみ移行し、S3/Redshift/Route53/CloudFrontは引き続き利用。EMR/SESも引き続き少し利用している
• RDSやDynamoDBはもともと使っていなかった（従来からEC2のMySQLとRedisを利用）
移行の概要
• 費用削減のため(́・ω・`)
• 個人的にはAWSは決して高くないと思っているが、大きい会社だと一括購入のメリットが大きかったり会計上の仕組みなどもあり、カンパニー制なので独立採算の社内プロジェクトとしては移行したことで多大な費用削減になった（このへんは各社事情が違うと思います）
• とはいえ、トラフィックやデータ量が多くてCPUもDiskIOも多く使うシステム特性上、EC2だと多少割高に感じていたのも事実
• また、広告配信システムとして1年間運用してきて、トラフィックの量が見積もれるようになってきて、必ずしもEC2ほどのスケーラブルなインフラでなくても対応できるようになった
移行した理由
• DirectConnectを使ってAWSとOpenStackをプライベートネットワークでつないだ。しかし元のVPCはIP範囲の問題で直接つなげず、中間に踏み台となるDirect Connect用VPCを置く必要があった
• 移行の瞬間にはバッチは数時間停止させ、配信サーバーは無停止で移行
移行手順
利用していたAWS VPC DirectConnect用AWS VPC 移行先のOpenStackネットワーク
DB DBHAProxy
App Appアプリサーバーは同じものを作成してDNS切り替え
DBサーバーはHAProxyを介してレプリケーションして移行の瞬間に切り替え
移行中のRead/Write
• 基本的にはほとんど変わらないという印象
• ELBを使えないためアプライアンスのロードバランサに対応した設定にし、ELBでSSL Teaminationしていた部分をフロントにnginxを置くようにしてnginxでhttpsも受けるように変更。 内部ELBを使っていた部分はHAProxyに置き換えた
• Amazon LinuxからCentOSにする際のパッケージの細かなバージョン違いでつまづいた
• MySQL(5.5)からMariaDBにも移行したが特に問題なし
移行時のトラブル・気づいた点など
Chef SoloからChef Serverへ
• EC2時代はfabric + chef-soloという構成を取っていて、 fabricがbotoを通してEC2のInstanceおよびRoleの管理を行うようにしていた
• 2年以上前に作った仕組みをベースにしているので、Knife-Soloですらなく、cookbookやroleのファイルを各サーバーにrsyncしてfabricからchef-soloをキックするという実装
• これをChef Serverに置き換え、fabricでInstance管理をかなりやっていた部分をChef Serverで一括管理するようにした（作業進行中）
移行の概要
• Chef Serverにツールを統一して社内インフラチームに管理を任せられるようにするため
• Chef Serverのインタフェースを通してノードや設定を検索したり操作したりできるようにすることで、より動的で強固で便利なインフラが作れそうな気がした（まだやってない）
移行した理由
• 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を持ったりしていた。これ以外にもクラスターに参加するノードを選んだり、レプリケーションすべきノードを自動で決定したりといろいろ考えられる
• development/staging/productionでそれぞれ別の設定を使いたいときのベストプラクティスがまだ良くわからない
• Chef Soloのときはgitレポジトリに全ての設定があったので、環境ごとにブランチやリビジョンを切り替えて開発していた
• Chef Serverになると、cookbookなどをアップロードすると全ての環境に適用になってしまうので、environmentsでcookbookの（chef serverの）バージョンを指定しているのだが、ここを更新ミスするとリリース漏れになったり巻き戻ったりしてしまう
• RoleやDataBagsはバージョン指定できないので考え方を変える必要がある
• Chef Serverがノードの状態を保持していることを意識する必要がある
移行してみて(2)
• 移行自体がスムーズにいったのはもともとAWSのコアなサービスをあまり使っていなかったから。ロックインを避けたかったのだが、AWSを使うならもっといろいろなサービスを組み合わせて使うべきかもしれない
• Chef ServerはChef Soloの単なる上位互換という感じでもなく、いくつか考え方を変える必要がありそう
• オンプレミスのサーバーにしたことで、深夜サーバーを自動で止めたりオートスケーリングを考慮したりといったことが無くなった
まとめ