ここ3年におけるサイバーエージェントのネットワークを取り巻く環境の変化 / cyberagent-adtech-network-for-these-3years

by komeinw

Slide 1

Slide 1 text

ここ3年におけるサイバーエージェントのネットワークを取り巻く環境の変化 CyberAgent アドテク本部山本孔明 @komeinw

Slide 2

Slide 2 text

自己紹介 ❏ 山本孔明@komeinw アドテク本部のインフラ組織（CIA）所属のネットワークエンジニア主な業務 ● オンプレとパブリックのネットワーク(物理/仮想) ● OpenStack / CircleCI ● Aritifactory ...etc ● チームマネジメント

Slide 3

Slide 3 text

本日のアジェンダ 1. サイバーエージェントとアドテクスタジオについて 2. アドテクスタジオのプライベートクラウドについて 3. 3年の変化を振り返ってみる a. スタートライン b. 一歩進んだ c. もう一歩進んだ d. その他 4. まとめ

Slide 4

Slide 4 text

サイバーエージェントについて 1998年の創業以来、インターネットを軸に事業を展開し現在では代表的なサービスである「Ameba」をはじめ、スマートフォン向けに多数のコミュニティサービスやゲームを提供しています。 and m ore !!

Slide 5

Slide 5 text

サイバーエージェントの事業内容

Slide 6

Slide 6 text

アドテクスタジオについてインターネット広告において、広告配信の最適化やメディアの収益最大化という観点からアドテクノロジーの重要度が高まっています。サイバーエージェントではアドテクノロジー分野におけるこれらのサービスについて各子会社を通じ開発しておりましたが、各サービスの開発部門を横断して組織化する専門部署としてアドテク本部・アドテクスタジオが設立されました。

Slide 7

Slide 7 text

https://adtech.cyberagent.io/pr/archives/3601 サイバーエージェントのアドテク

Slide 8

Slide 8 text

サイバーエージェントのアドテク詳細は「日本一やさしいアドテク教室」を御覧ください！ https://adtech.cyberagent.io/pr/archives/3601

Slide 9

Slide 9 text

アドテクスタジオのインフラってどうなっているの？

Slide 10

Slide 10 text

アドテク本部のインフラってどうなっているの？ ● 25を超えるプロダクト。約200名のエンジニア。 ● インフラは各プロダクトで自由に選択 ● AWS、GCP、プライベートクラウドインスタンス数ベースでは　プライベートクラウド＞ AWS ＞ GCP 　最近、GKE のために GCP を利用するケースが増えてきている

Slide 11

Slide 11 text

アドテクスタジオで提供しているプライベートクラウドについて

Slide 12

Slide 12 text

プライベートクラウドについて ● 本番用クラウド基盤 ○ OpenStack (Izanami) ● コンテナ基盤 ○ AKE ● CI周り ○ CircleCI ○ Artifactory ● 物理マシン ○ MAAS ● 個人開発用クラウド基盤 ○ OpenStack (Mille) ＋ Midonet ● 分析基盤 ○ Tableau

Slide 13

Slide 13 text

Meet Adtech Cloud Circle CI Enterprise 2.0 を βリリース中

Slide 14

Slide 14 text

ここ3年を振り返ってみる

Slide 15

Slide 15 text

スタートライン ● 2014年3月 ○ @komeinw 入社した時点の情報 ○ 1U 物理サーバを大量に並べたラック構成 ○ KVM で VM 数台起動 ○ PXE boot で OS 入れて引き渡し ○ NW はコアに L2SW を LAG で接続する構成 ○ 申請ベースの作業例えば、LBの設定などエクセルで来る申請をポチポチ手作業で実施していた。サーバ担当がラック作って、ネットワーク担当がスイッチの設定して、サーバ担当が OS 入れて KVM 上に VM 作って、開発者がアプリケーション入れて LB 申請してくる流れ

Slide 16

Slide 16 text

Excel での申請作業って・・・ ● ヒューマンエラーおきやすい ○ コピペミス ○ １行ズレた ○ 大文字小文字間違えた ● なので、確認作業にも時間がかかる ● Excel からコンフィグ生成する案もあるが・・・　　集中している作業を分断されるのは変わりない

Slide 17

Slide 17 text

一歩進んだ ● 2014年8月 ○ OpenStack になった。セルフサービス。 ○ NW はよくある L2 構成にした（当時NeutronのL3は・・・） L3 と LB が物理の世界に取り残さることにより、申請作業が変わらない問題は残る。というより、より課題が顕著になる恐れが。

Slide 18

Slide 18 text

一歩進んだインフラ用の API Gateway を作成。 API を公開すると共に「AXC (Adtech Studio X Cloud) 」をリリース。簡単にアドテク内のインフラリソースを操作できるように。 Python 製。GitHub の organization 内で公開して配布。※ API Gateway がないと動かない https://adtech.cyberagent.io/techblog/archives/59　　

Slide 19

Slide 19 text

操作イメージと効果 • 学習コストが低い（アプリケーションの開発者が　各製品固有のコマンドを覚える必要がない） • メーカーの差を隠蔽できる • 簡単にJOBに組み込んだりすることが可能 • 思い立ったときにすぐインフラの操作ができるこんな感じでのルータ・スイッチ・ロードバランサー、Neutronの設定ができる。 Regionの概念も持たせています

Slide 20

Slide 20 text

Chatで話かけると・・・ SVI / VLAN作成、LB設定、Neutron設定、テスト、テスト環境削除までの一連の流れを実施。結果はChatで通知。面倒なものは chatbot も（１）

Slide 21

Slide 21 text

面倒なものは chatbot も（２） • グラフィカルな部分はChatでできるようにしておくと便利。 • “頼まれる側” も ”頼む側” に取ってもストレスフリー • 他にも可視化と簡単なプロビジョンで活用 • Jobに組み込んだりする可能性があるものは CLIないしはAPIで提供した方がよい

Slide 22

Slide 22 text

もう一歩進んだ ● 2015年2月 ○ OpenStack + SDN で開発者向けの個人環境を構築 ○ OpenSource になったばかりだったが Midonet を採用 Zookeeper と Cassandara ネットワーク情報を管理し、各サーバ(Controler / Compute)で動作する Agent が OpenStack と連携しネットワークを作る。 VTEP の位置を考えるとネットワークはリーチャビリティがあれば難しい処理はしなくてよい http://www.sdnjapan.org/archive/2015/2015pdf/1503_hasegawa.pdf 自動化の限界、 VLAN自体を管理するのが面倒 →

Slide 23

Slide 23 text

作業からの解放＼(^o^)／

Slide 24

Slide 24 text

トラブルシュートが変わってくるネットワークエンジニアとしては Linux で構成される世界を管理するかしないかでやるレベルに大きな差がでる ● 「ネットワークがおかしい」ってどこまでの範囲？ ● TAP？　qbr？　qvo？　qvb？　 ● SoftIRQ 周り？ Adapter の queuing ? netdev_budget ? backlog ? ● zookeeper で管理しているネットワークがおかしい？ ● midonet の bug ? neutron との不整合？ユーザからすると、インスタンスから外に出れば管理者の範疇。仮想ネットワークとか物理ネットワークとかは区別して問い合わせをしてくるわけではない。

Slide 25

Slide 25 text

もう一歩進んだこの辺りからエンジニア間の垣根がなくなってくる現在は、得意分野は違えど全員が同じ業務を遂行できる（ネットワークは除く） Server Server Network Network API公開守備範囲拡大

Slide 26

Slide 26 text

さらにもう一歩進んだ ● 2016年11月 ○ Kubernetes as a service を始動 ○ 2017年1月に β をリリース ○ 現在は OpenStack 上で複数のクラスタが稼働しているコンテナの需要の高まりへの対応、Kubernetes を as a service 形式で稼働できることで開発エンジニアがコンテナのメリットを受けるためのハードルを避ける AKE(Adtech Container Engine) OpenStack 上に専用の Kubernetes を気軽に構築できる環境 https://adtech.cyberagent.io/techblog/archives/3673

Slide 27

Slide 27 text

● Google 社が作った COE ツール ● Docker コンテナのオーケストレーションを行う ○ スケールアウト、スケールイン ○ リソース管理、スケジューリング ○ ロードバランシング、ヘルスチェック ○ BlueGreen、ローリングアップデート ○ クラスタ間ネットワークの提供 ● コンテナをよしなに管理してくれる Kubernetes ってなに？

Slide 28

Slide 28 text

AKE や GKE の何がいいのか？ ● Kubernetes を構築するのが辛い問題... ○ あまり本質的な所ではないので楽をしたい ○ ≒ OpenStack を構築する ● Kubernetes クラスタを簡単にデプロイ ● Kubernetes Node 自体を簡単にスケーリング ● 動的な永続ボリュームの提供（Persistent Volume の Dynamic Provisioning）

Slide 29

Slide 29 text

Step 1. AKE / GKE クラスタを構築する Step 2. Kubernetes で Pod/Service を作成する GKE AKE

Slide 30

Slide 30 text

Step 1. AKE / GKE クラスタを構築する Step 2. Kubernetes で Pod/Service を作成する GKE AKE (AKE)# ake cluster create NAME ... (GKE)# gcloud container clusters create NAME ...

Slide 31

Slide 31 text

Step 1. AKE / GKE クラスタを構築する Step 2. Kubernetes で Pod/Service を作成する GKE AKE (AKE)# kubectl ... (GKE)# kubectl ...

Slide 32

Slide 32 text

AKE を実現するために必要なこと ● OpenStack 上に必要なリソースを展開する ● Kubernetes をインストールする（最近イメージに内包した） ● LoadBalancer に登録する（ or LoadBalancer 自体の構築） ● CLI の提供 ● master や worker のスケールイン / アウト ● 提供する Kubernetes の CI / CD ● CLI の CI / CD ● ....etc

Slide 33

Slide 33 text

OpenStack Heat とは？ ● 構成情報を template で管理することができる ● AWS CloudFormation / Terraform に近い OpenStack 上に必要なリソースを展開する

Slide 34

Slide 34 text

Kubernetes 時代のネットワークの苦労ポイントを一つ紹介

Slide 35

Slide 35 text

type: LoadBalancerの壁 ● Kubernetes には Service を「type: LoadBalancer」で作成すると Cluster 外に LoadBalancer が作られる仕組みがある ● この Service を使うと Cluster 外部から内部の pod にアクセスが可能 ● 様々な Cloud Provier 連携が存在 (GCP / AWS / OpenStack …) ● OpenStack の場合は Neutron LBaaS か Octavia と連携される ● しかし、アドテクの OpenStack では Neutron LBaaS も Octavia も無い

Slide 36

Slide 36 text

type: LoadBalancerの壁（解消ポイント） ● もともとアドテクスタジオでは Hardware LoadBalancer を使用しているが、その LB に対して API で操作できる AXC という仕組みがある (前述の Adtech x Cloud) ● Kubernetes からの LoadBalancer の作成時にこの AXC と連携させれば「type: LoadBalancer」が実現できる ● Kubernetes の Cloud Provider の OpenStack の pkg を改修 ● しかしこれだけではまだ完全ではない ● LoadBalancer 用の IP Address を自動で払い出す機能も作成

Slide 37

Slide 37 text

おまけ：Chatbot も進化している簡易版。LB のヘルスって落ちてないですか？という質問が多かったので。アラートに bot が反応してくれたり、別の bot を呼び出して処理をするようになっている

Slide 38

Slide 38 text

まとめ ● ネットワークエンジニアの領域は変わってきている ● OpenStack / SDN / Kubernetes によるインフラ環境の変化が起きている ● 単純作業から解放されれば、別のことをやる時間が作れる ● いろいろ情報交換していきましょう