Downloaded 103 times
Uploaded byVirtualTech Japan Inc.
OCP, Kubernetes ハイパースケールアーキテクチャ 導入の道のり - OpenStack最新情報セミナー(2016年7月)
OCP, Kubernetes ハイパースケールアーキテクチャ 導入の道のり - OpenStack最新情報セミナー(2016年7月) 講師：松谷 憲文（YJ America） アジェンダ： - 会社紹介 - YJ America アーキテクチャ設計思想 --- 事例1. Hadoopインフラ設計 --- 事例2. コンテナ環境の構築 - まとめ
More Related Content
Similar to OCP, Kubernetes ハイパースケールアーキテクチャ 導入の道のり - OpenStack最新情報セミナー(2016年7月)
OCP, Kubernetes ハイパースケールアーキテクチャ 導入の道のり - OpenStack最新情報セミナー(2016年7月)
- 1. ハイパースケールアーキテクチャ 2016/7/28 YJ America Norifumi Matsuya OCP,Kubernetes 導入への道のり
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. 経済産業省 エネルギー白書 2015(http://www.enecho.meti.go.jp/about/whitepaper/2015gaiyou/whitepaper2015pdf_h26_nenji.pdf) 米国における電気料金事情 参考: Map of average US residential electricity price by utility service territory (http://en.openei.org/wiki/File:2012_12_14_Electricity_Price-01.jpg) データセンタ総コスト 約22%減を試算
- 8. • 2014年10月にYahoo! JAPANの米国現地法人を設立 •既設のデータセンタを購入し、 2015年4月ワシントン州データセンタの稼働 • 組織 • カリフォルニア州 5名（ビジネス＋ビックデータ） • ワシントン州 4名（インフラ＋アドミン）
- 9. • 2014年10月にYahoo! JAPANの米国現地法人を設立 •既設のデータセンタを購入し、 2015年4月ワシントン州データセンタの稼働 • 組織 • カリフォルニア州 5名（ビジネス＋ビックデータ） • ワシントン州 4名（インフラ＋アドミン） 自分はこちらのチーム
- 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. Open Compute Project •Facebookが2011年にサーバなどのハード ウェアの設計図や仕様のオープンソース化を推進 する非営利組織として発足したコミュニティ • 現在は１50社以上が加盟
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46. Chassis MB CPU Memory DiskCardOEM/ODM 調達方式の変化 価格低減の選択肢が広がる サーバ毎ではなくパーツ毎で在 庫保持可能
- 47.
- 48.
- 49. 参考: Kubernetes onOpenStack at eBay, Aswin Nair, eBay (https://www.youtube.com/watch?v=l5HpUNhpKwU) OpenStack Day Seattle 2015 ”Kubernetes on OpenStack” @eBay 既存環境(OpenStack)は 利用したい
- 50. eBayがOpenStackと Kubernetesを連携 参考: Kubernetes onOpenStack at eBay, Aswin Nair, eBay (https://www.youtube.com/watch?v=l5HpUNhpKwU) OpenStack Day Seattle 2015 ”Kubernetes on OpenStack” @eBay 既存環境(OpenStack)は 利用したい
- 51. そのBorg開発者がKubernetes を開発している Google Borg 10年以上稼働のGoogleのコンテナシステム 2billion/week launch 参考:Large-scale cluster management at Google with Borg (https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/43438.pdf)
- 52. そのBorg開発者がKubernetes を開発している Google Borg 10年以上稼働のGoogleのコンテナシステム 2billion/week launch 参考:Large-scale cluster management at Google with Borg (https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/43438.pdf) 大規模運用をターゲットに 開発
- 53.
- 54. プロセスを増やすと非効 率になりがち Code Control Image Creation Deployto Platform リリースプロセス
- 55. プロセスを増やすと非効 率になりがち リリースプロセスの 標準化も一緒に考える Code Control Image Creation Deployto Platform リリースプロセス
- 56. 非効率にしない Appコードは１つで３つ の環境にdeployするよう にTool chainは統一 Image creationCodecontrol Deployment Platform Bare Metal & VM Container
- 57. Image creationCode controlDeployment Platform Bare Metal & VM Container 本日はコンテナ向け Tool chainの説明
- 58. Code Code Management Instance Authentication Persistent Volume Container Engine ContainerCluster Manager Container Networking Service Registry Container Registry Infrastructure Provisioning APP APP APP logging Metrics Heapster CI tool Service Monitoring 全体アーキテクチャ - Kubernetes on OpenStack - GitHub、etcd以外はコンテナで稼 働 - CI toolや各種管理ツールも Kubernetes上で稼働 - Kubernetesの上でOpenStackも稼 働させる “Manage application, Not Machines” KubernetesにはIaaSが必須 逆にどんなIaaS上でも稼働可能
- 59. Image creationCode controlDeployment Platform Bare Metal & VM Container Container Image creation flow 最初に実行イメージを自 動で作成、その後 Artifactoryに格納までを 説明 どのフローもImage 作成できればdeploy は簡単 （OS、k8s以外でも）
- 60. Master Slave Service Job Dockerfile repository Build.sh docker build Docker image Dcoker image DockerHUB New Docker image 1 2 3 4 5 8 69 7 Container Image creation flow 1. GitHubへCodeをpush 2. JenkinsのMasterへ 3. Jenkinsのslaveでジョブを立ち上げる 4. Dockerfile repositoryをcheckout 5. Service Jobを実行 6. Artifactoryからbase docker imageをダウンロード 7. Artifactory上にdocker imageがない場合はDocker Hubか らダウンロード 8. Docker buildを行いimageを作成 9. 出来上がったimageをArtifactoryへアップロード
- 61. Image creationCode controlDeployment Platform Bare Metal & VM Container 次に実行イメージの deploy先である、 Kubernetesの説明 Kubernetes Architecture
- 62. VM KubernetesMaster VM Keystone Cinder VM etcd proxy kubelet kubeproxy Pod App App App Pod App App Pod App App App Pod App KubernetesNode P Calico Dockerengine Pod etcd proxy kubelet kube-apiserver P CalicoDockerengine Pod kube-scheduler Pod kube-controller-manager Pod VM etcd proxy kubelet kube proxy Pod App App App Pod App App Pod App App App Pod App KubernetesNode P Calico Dockerengine Pod - クラスタを管理するMasterとコンテ ナが実行されるNodeがある - コンテナの集合をPodという - Kubernetesの認証はバックエンドに Keystoneを使用 - 認可はKeystoneの情報から Kubernetesのpolicyファイルへスク リプトで変換 - 外部ストレージとしてCinderを利用 - ネットワークはProject Calicoを利用 Kubernetes Architecture
- 63. VM Kubernetes Master VM Loadbalancer Node VM Pod App App KubernetesNode VM Pod App Kubernetes Node Pod App App iBGP iBGP iBGP iBGP Route Reflector & Gateway Redistribute ClusterIP and Pod IPs to Backbone Advertise Pod IPs(/26) Advertise ClusterIP Advertise PodIPs IP(/26) ClusterIP range : 10.0.0.0/22 Pod IP range: 192.168.0.0/22 Node IP range: 172.16.0.0/22 Kubernetes Networking - Route Reflectorと各VMがiBGP接続 - 各NodeへPod用アドレスレンジがア サイン後（Blackholeの設定もされ る）、iBGP経由で広報 - Pod起動時にアサインされたアドレ スレンジよりIPが振られる - PodのアドレスをBackboneへ再配布 することにより他のクラスタからも Podへアクセス可能になる
- 64. 192.168.0.0/24 ClusterIP: 10.0.0.100 200.0.0.100 Src addressDst address ① 200.0.0.100 10.0.0.100 ② 172.16.0.100 192.168.0.100 ③ 192.168.0.100 172.16.0.100 ④ 10.0.0.100 200.0.0.100 VM Loadbalancer Node VM Kubernetes Master VM Pod App App Kubernetes Node ① ② ③ ④ Pod IP: 192.168.0.100 Node IP : 172.16.0.100 ClusterIP range : 10.0.0.0/22 Pod IP range: 192.168.0.0/22 Node IP range: 172.16.0.0/22 External Service Load Balancing KubernetesのExternalのロードバランス方式 は複数あるが要件に合うものが存在せず Internalのロードバランス方式をExternalでも 使えるように工夫して解決 1. ClusterIPが広報されているNodeへ 2. DNAT/SNATをしてパケットを送出 ※SNATはKubernetesのデフォルトの動作で ないので注意 3. 送出されたNodeへ 4. NATの逆変換を経てクライアントへ
- 65. Docker registry Jenkins Master LaunchJenkins slave Pod and run command hook Upload Artifactory pull repository issue tracking track commit build result CI support Kubernetes Cluster master deploy APP Cinder Persistent Volume Keystone Auth Tenant Isolation push Launch Pod pull image master APP Cinder Persistent Volume Keystone Auth Tenant Isolation Launch Pod Kubernetes Cluster #1 for Datacenter A Nova Nova Boot Kubernetes node OpenStack Admin Docker build master Boot Kubernetes node Kubernetes Cluster #2 for Datacenter B Code Control Image Creation Deploy to Platform OpenStackクラスタ 数が30以上 OpenStack on Kubernetes on OpenStack で効率良く管理
- 66. APP Openstack Cluster #1 forDatacenter A Glance CI support Kubernetes Cluster push OpenStack Admin qcow2 Image Teraform Packer Code Control Image Creation Deploy to Platform おまけ KubernetesもImage deploy APP Openstack Cluster #2 for Datacenter B Glance
- 67. まとめ • 限られたリソースでは割り切りが必要で、ハイパー スケールアーキテクチャは強力な選択肢となり得 る • 自社特有の未解決の問題にリソースをつぎ込む •世界基準のアーキテクチャやアーキテクトと仕事す るのは何よりも楽しい
- 68. Techblogにも公開しています - Kubernetes http://techblog.yahoo.co.jp/infrastructure/os_n_k8s/ - OpenCompute Project http://techblog.yahoo.co.jp/operation/2015-10-ocp/ ご静聴ありがとうございました
Editor's Notes
- #2 こんにちは 米国ヤフーが大変になっていますが、YJ Americaはヤフージャパンの子会社なので元気良く行きたいと思います。
- #3 まず、はじめに会社紹介をしたいと思います
- #4 この円グラフですがヤフージャパンのデータセンタコストのグラフになっています
- #5 約２６％が電気代となっております。 非常に大きな数字ですね。
- #6 しかも数年前から日本の電気代は上昇傾向あります。
- #7 数年前の調査ですが、アメリカは電気代が安いことが分かりました。
- #8 電気代が1/6になると、データセンタ総コストが２２％削減できるということになります。これは相当大きな数字ですね。
- #9 といった経緯でヤフージャパンはアメリカにデータセンタを作ることにしました。 ２０１４年に現地法人を設立して、２０１５年にはデータセンタの稼働を開始しました。 現在はカリフォルニアに５名、ワシントン州に４名で総勢９名の会社となっております。
- #10 私はワシントン州の方に赴任しております。 自然が多くてとても良いところです。 データセンタ見学も行っているのでご希望の方はお気軽にご連絡ください。
- #11 突然ですがこちらの数字なんの数字だかわかりますか？ ？ ？
- #12 OpenStackミタカのプロジェクト数です。 結構ありますよね。 自分がOpenStackをはじめたのは2010年くらいですがその時は６つ？７つ？くらいだった気がします。
- #13 ほかにもサテライトプロジェクトも多数あるので、全体を把握するのは相当な労力が必要ですよね。
- #14 結果、OpenStackを導入しようとすると調査コストが膨大になってしまってるのではないかと思います。
- #15 また、これだけプロジェクトがあるとプロジェクト連携が複雑になり設定するのも難しいのではないでしょうか。
- #16 さらにOpenStack導入部門はインフラであるサーバ、ネットワーク、Operating systemなどの設計も行わないといけませんね。
- #17 プロジェクトが増えて色々できる事はとても良いことですが、選択肢が多すぎるもの困ったと感じている人も多いのではないでしょうか。
- #18 OpenStackだけでなく、今日のシステムはシステム間連携が非常に多く、アーキテクチャ設計自体がとても難しくなっていると考えます。 また、選択したシステムが数々のシステムの中で生き残れるか判断するのは非常に難しいですよね。
- #19 そこでちょっとまずはYJ Americaの設計の仕方というか、思想を説明したいと思います。
- #20 日本で仕事している時と比べて環境に大きな違いがありますので、まずはそこを説明したと思います。
- #21 まず、インフラ部門は私を含めて３名と非常に少ないです。たまに日本からも１ヶ月くらいヘルプが来てくれます
- #22 次に赴任期間があります。ビザの関係上３−５年が一般的です。
- #23 その期間内に成果を出さないといけないので時間はほとんどありません。
- #24 アメリカに来て一番思うことですが、すごい人が本当たくさんいます。我々なんて本当未熟だなととても思います。
- #25 GoogleやFacebookといったハイパースケール企業のように0からシステムを作るのは10年かかっても無理でしょう。
- #26 そこで注目しているのはハイパースケール企業が考えているアーキテクチャです。
- #27 スタンダードな構成をスケールアウトするモデルなので、構造がとてもシンプルです。
- #28 シンプルが故に関連システムとの設計もそこまで難しくなく、導入が比較的簡単です。
- #29 彼らのアーキテクチャでOSSにしているものだったら、その普及にかなり力を入れています。
- #30 故に、普段だったら全体話を聞けないような人からアドバイスを貰えることが可能です。
- #31 ハイパースケール企業で利用されているシステムは長年にわたりサービスを支えてきています。
- #32 故に我々が把握できてないような課題も解決済みであったりする事があります。
- #33 さて、以上の事を前提に、Y Americaで導入した２つの事例について説明をしていきたいと思います。 まずはHadoopのインフラ設計です。サーバやネットワークといった機器の構成を決定するのがゴールでした。
- #34 YJ AmericaのデータセンタにHadoopのインフラを導入するための課題を再確認したいと思います。
- #35 まず、先ほども話しましたが人数が３名しかいないため、運用リソースに問題があります。
- #36 また、今回購入したデータセンタは数年前のデータセンタであるため、電力設計も古く、スペースあたりの使用可能電力量が少なくなっています。
- #37 次に、まだアメリカに来たばかりだったので購入ルートの選択肢が乏しく、通常のあいみつでは限界があると感じていました。
- #38 という課題をクリアするためにOpen Compute Projectに興味が出てきました。 OCPは 2011年にFacebookが利用しているハードウェアをオープン化した団体です。 OCPで公開されているサーバはFacebookで実際に利用されているハードウェアです。
- #39 FacebookのOCPサーバはメンテナンスがすべて前面からできるように設計されています。
- #40 Facebookは、１台あたりのメンテナンス台数を25000台にするために、パーツ交換を１５分で終わらせる必要があったと言っていました。 僕らのような人数が少ないデータセンタでも問題なく運用できますね。
- #41 また、電源ケーブルがありません。サーバはトレイの上でスライドさせることで電源と接続されます。
- #42 実はデータセンタの運用事故で最も多いのは電源ケーブルの抜き差しです。 この運用ミスが０になる構造って結構すごいですよね。
- #43 また、OCPのサーバには電源が付いていません。電源部分はラック内で集中管理されています。
- #44 集中的に管理することにより高効率給電が可能となっており、電気の無いデータセンタでも有益な構造になっています。
- #45 また、最大なメリットだと思いますが、FacebookのOCPサーバって購入可能なサーバで世界一の可動実績なんですよね。 メーカーのサーバではモデルもばらけているでしょうし、可動実績ということでしたらきっと世界一でしょう。
- #46 実は今回のhadoopの構成はOCPと普通のサーバを半々で購入しました。 結果、OCP構成の方が問題が少なかったです。この辺も数十万台？といった可動実績があるからではないでしょうか。
- #47 加えてコストの面ですが、従来型のサーバと購入方法が違っていて、各パーツメーカと直接交渉します。メーカ同士のあいみつだけでないので、価格低減につながる選択肢が増えました。 また、サーバ毎に在庫を持つ必要が無いため在庫管理も非常に楽になりました。
- #48 次の事例に進みたいと思います。次はコンテナ環境の構築です。
- #49 コンテナ自体はDocker選択肢以外ないと考えていましたが、オーケストレータはいろいろな種類があるので、選択するのにいろいろ迷いました。
- #50 リソースがないので既存環境であるOpenStackはなるべく利用したいと考えていました。
- #51 OpenStack Day SeattleでeBayさんがKubernetes on OpenStackというセッションを行っていて、Kuberneteとうまく連携させていました。
- #52 Kubernetesの開発者は、Googleで１０年以上も可動しているコンテナシステムの開発者と聞きました。
- #53 Borgには１００を超える機能があるとのことでしが、どんどんKubernetesにも取り入れていくぜと言っておりました。
- #54 他のオーケストレータの人にも直接話を聞いたりましたが、Kubernetesが一番要件にマッチしていると考え導入を決めました。
- #55 さて、ヤフージャパンにはOpenStackがすでに運用されていて、アプリケーションの開発者から見ると単にプロセスが増えただけに見えてしまうかもしれません。これはとっても非効率です。
- #56 ですので、今回は一緒にリリースプロセスの標準化も一緒に考えることにしました。
- #57 具体的に説明しますとアプリケーションのコードは１つで、GitHubで管理します。 環境に合わせてイメージクリエーションのフローを作ります。 OpenstackもKuberneteもイメージがあればdeployは非常に容易なので、図のようなツールチェーンにしました。
- #58 ですので、実際はフローとしては３つあるのですが、本日は時間の関係もあるのでコンテナイメージのツールチェーンを説明したいと思います。
- #59 ちょっといろいろあって複雑ですが。。 <右上の文の説明> Kubernetesは“manage application not machinens”と歌っていて、Openstackも一つの選択肢ですが、他のクラウド上でも簡単に動くような設計になっています。
- #60 まずはイメージ作成方法の説明です。 先ほども説明した通りイメージ作成までできれば、どのフローもデプロイはそんなに難しくありません。
- #61 図の通り、Kubernetes用といっても、ようはdockerイメージを作成すれば良いだけなのでとても簡単です。
- #62 次に実行イメージのdeploy先であるKuberntesの説明をしたいと思います。
- #63 アーキテクチャは図の通りです。
- #64 ネットワークの説明を少ししたいと思います。
- #65 External service load balancingの説明をしたいと思います。
- #66 説明したimage creationのフローとkuberntesを組み合わせてtool chainを作成しました。 このtool chain上にOpenstackのコントローラを稼働させる事によりOpenstack自体の管理も容易にする事ができます。
- #67 また、おまけですが今回説明できなかったVM image creationのフローを使って、kubernetesの構築も出来ます。