GMOインターネット様 発表「OpenStackのモデルの最適化とConoHa, Z.comとGMOアプリクラウドへの適用」 - OpenStack最新情報セミナー 2015年12月

Editor's Notes

• #2: Hi everyone. We are from a team at GMO Internet that focuses on developing services based on Openstack. My name is Hyuntae Park and I am a manager of this team being involved in many Openstack projects. We recently released a public cloud service called ConoHa which was built Openstack Juno. We have always been developing products for Japan market but this product is targeted for users globally. We’ve developed virtual server products in the past but all of them are a very simple product for users in Japan. Because ConoHa is targeted for users globally, we faced architecture challenges that we didn’t have before. One example is “Multi Region”. I’d like to introduce ConoHa multi region structure and our operation know how.
• #3: The agenda for today is as shown in this slide. Introduction to OpenStack based services we developed in the past. Overview of Multi Region. Our original extensions to OpenStack. Multi region supported Domain
• #4: 最初に、GMOインターネット株式会社についてです。 我々GMOインターネットは、「日本を代表する総合インターネットグループへ」というコーポレートキャッチで、インターネットに関する様々なサービスを展開しています。 現在GMOグループは、連結対象が86社、うち上場企業8社、もうすぐ9社になります、そして約4400名のインターネットのプロフェッショナル集団で運営されている、東証一部上場企業グループです。私たちは、1999年8月にインターネット企業として、日本で最も早く上場しました。 現在は「日本を代表する総合インターネットグループ」を目指し、4つの事業領域で展開しています。
• #5: すみません、このページは一部日本語なのです。 我々がインターネットのインフラ事業と読んでいる事業領域がこちらです。 我々のユーザーがインターネット上でビジネスを行うために必要なサービスをまとめて提供するものです。 例えば、 ドメイン(ドットコム、ドットネット、どっとジェーピーのようなものですね セキュリティ SSL 決済 ECサービス支援 そして広告などです。 ユーザーがこういったサービスを利用するに当たって、多くの場合サーバーやクラウドが必要になります。 我々のクラウドサービスは、ユーザのビジネスを支えるために非常に重要な事業です。 そして、さまざまなインフラ事業を全て自分たちで提供することで、サービス同士のシナジー効果を出すことができます。 このようにクラウド事業は、我々のインフラ事業を支える非常に重要な事業というわけです。
• #6: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #7: 我々は現在4つのOpenStackベースのクラウドサービスを展開しています。 クラウドのサービスに限らないのですが、GMOインターネットは、自社のサービスを自分たちの手で設計、実装、運用を行うようにしています。そうすることで、我々は経験とノウハウを蓄積することができ、一方でユーザーに対して最適なサービスをスピーディーに提供することができると考えているからです。 これらのうち、一番最初に登場したのが「お名前VPS」です。最初OpenStackをVPSサービスとして使っていました。次に右上のGMOアプリクラウドが登場し、右下のお名前.comクラウドが登場し、その後ConoHaが登場しました。 ConoHaは我々のOpenStackプロダクトの中でも、非常にアグレッシブなプロダクトだと思います。ConoHaにはOpenStackのコンポーネントをベースにした多数の機能があります。一方でOpenStackのAPIを公開しているので、ユーザーはOpenStackに対応したソフトウェア、サービスをそのままConoHa上で使うことができます。ConoHaは我々のプロダクトの中で、OpenStackの機能を一番フルに使っています。 このように、OpenStackを利用することで、我々は常にプロダクトを改善することができています。
• #8: Within all the services we’ve launched so far, we have 2,000 active physical node and over 100,000 VMs activated. I will dive into the newly released ConoHa’s features.
• #9: As Park san mentioned, multiple OpenStack clusters are operating in multiple Products within our environment. Primarily this is very inefficient in terms of cloud operation and it is off a principal of a fundamental business rule “selection and concentration”. Starting with the Diablo cluster, we’ve built many OpenStack clusters such as Grizzly, Havana and Juno and they are still in operations. In terms of Swift cluster, we share multiple OpenStack by deploying swift-proxy per Keystone auth. However, it takes a lot of time and cost to deploy OpenStack cluster each time. There is stackforge project called Tricircle that deals with OpenStack deployment across multiple sites but for now, we don’t want to complicate our operation. ========= 先ほどPark sanが話したように、我々の環境では複数のOpenStack clusterが複数のProductで稼働しています。 本来ならば、このようなことは、クラウド運用には無駄が多いですし、ビジネスの「選択と集中」の原則から外れますね。 Diablloのclusterから始まり、 Grizzly、 Havana、 Junoと数多くのOpenStack clusterを構築して、現在もサービスとして運用しています。 Swift clusterはKeystone authごとにswift-proxyを起動することで、複数のOpenStackから共有して利用しています。 しかし、毎回OpenStack cluster環境を構築するのは、工数もかかり大変です。 もちろん、OpenStackをCascadingするProjectでTricircle というのがありますが、いまのところ、より複雑な運用は我々の望むところではありません。
• #10: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #15: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #19: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #27: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #28: As Park san mentioned, multiple OpenStack clusters are operating in multiple Products within our environment. Primarily this is very inefficient in terms of cloud operation and it is off a principal of a fundamental business rule “selection and concentration”. Starting with the Diablo cluster, we’ve built many OpenStack clusters such as Grizzly, Havana and Juno and they are still in operations. In terms of Swift cluster, we share multiple OpenStack by deploying swift-proxy per Keystone auth. However, it takes a lot of time and cost to deploy OpenStack cluster each time. There is stackforge project called Tricircle that deals with OpenStack deployment across multiple sites but for now, we don’t want to complicate our operation. ========= 先ほどPark sanが話したように、我々の環境では複数のOpenStack clusterが複数のProductで稼働しています。 本来ならば、このようなことは、クラウド運用には無駄が多いですし、ビジネスの「選択と集中」の原則から外れますね。 Diablloのclusterから始まり、 Grizzly、 Havana、 Junoと数多くのOpenStack clusterを構築して、現在もサービスとして運用しています。 Swift clusterはKeystone authごとにswift-proxyを起動することで、複数のOpenStackから共有して利用しています。 しかし、毎回OpenStack cluster環境を構築するのは、工数もかかり大変です。 もちろん、OpenStackをCascadingするProjectでTricircle というのがありますが、いまのところ、より複雑な運用は我々の望むところではありません。
• #29: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #30: Based on the feedbacks we received from our users, we decided to upgrade ConoHa using the latest version of OpenStack. In order for ConoHa to be accepted by users all over the globe, we needed to make sure we have the following features. Multi region SSD ONLY Scalability API competitive pricing For the time being, I will focus on talking about the Multi region feature as it is very unique.
• #31: Park san has talked about the region strucutre in Multi-Region and how it works in ConoHa cloud environment. We have more to that. And they are, Application to multi location region structure (Domain structure). Application of one domain to 1 OEM service or product service. I’m going to dive into the details of these 2 features. ========= ここまで、Park sanにMuli-LocationにおけるRegion構成について、我々のConoHaのクラウド環境での適用をお話しました。 ConoHaインフラでは、さらにもう一工夫しています。 それは、次の内容になります。 ドメイン構造のマルチロケーション・リージョン構成への適用 一つのドメインを一つの製品サービスまたは、OEMサービスへの適用 これらの側面をさらに適用した話をします。
• #32: I’d like to take a few minutes to go over the definition of each terms. When I say Domain, it refers to the Keystone Domain. I will talk specifically about the domain that is operated with the Keystone V2 API. I will also talk about the Designate DNS domain but that’s not all. Location means areas that are physically in a location that are far from each other. In our cases, they will be US (San Jose), Japan (Tokyo) and SG (Singapore). Region refers to OpenStack region. Which means that Location and Region are not used as same meanings. There are caseswhere we set up multiple Region in one Location. ========== ちょっと、ここからの単語について、前もって定義しておきます。 ここから、Domainとは、主にKeystone doaminのことです。 その中でも、我々が設定したKeystoen V2 APIで運用しているdomainについて、主に言及します。 DesignateでのDNS domainについても話しますが、ここでのドメインはそれだけではありません。 Locationとは、地域的に遠い場所にあるところを意味します。 我々の環境では、US(San Jose), JP(Tokyo), SG(Singapore)になります。 Regionとは、OpenStack regionを指します。 LocationとRegionは同一ではないです。 ゆえに、同じLocationにRegionを複数設定することもあります。 ==========
• #33: Supporting multi region was our first priority out of all the features in the roadmap. Physical location of the servers means a lot to our users. The data center location we chose initially were Tokyo, Singapore and San Jose. We’ve successfully built a multi region architected OpenStack environment between the 3 locations.
• #34: Now I’m going to explain the actual process we took to architect multi region. The OS and OpenStack version for ConoHa areas shown. We were able to build it just by connecting to Tokyo KeyStone from all regions and adding each region endpoints to Tokyo KeyStone. We of course didn’t have to modify any of OpenStack codes.
• #35: Restriction 1: The system that manages both service site and user information only exists in Japan. Therefore user registration was only available in Japan.
• #36: Restriction 1: The system that manages both service site and user information only exists in Japan. Therefore user registration was only available in Japan. Restriction 2：We of course use 10G network interface for connection between physical server and Switch but the network used for data base replication within the Region is a VPN of 10Mbps so it is not stable. Restriction 3: As we anticipated 10s of thousand of token issues per day, it was clear that the table capacity was not suitable for long distance replication. Although we were able to delete all the tokens that was automatically issued by components such as glance and neutron, we still anticipated a tremendous amount of queries. I will talk more about it in the next page.
• #37: Restriction 3: As we anticipated 10s of thousand of token issues per day, it was clear that the table capacity was not suitable for long distance replication. Although we were able to delete all the tokens that was automatically issued by components such as glance and neutron, we still anticipated a tremendous amount of queries.
• #38: The procedure we use for internal transaction, we were able to reduce the Token by setting up token with expiration date of 100 years to each components of neutron and glance. As per the 3 restrictions I’ve mentioned, we had to give up the initial idea of a very simple multi region structure. We separated the KeyStone functionality with the data base and then picked out the ones that requires region to region replication and the ones that doesn’t. Handling data replications that are in 3 different regions with a very narrow bandwidth, we knew there was a chance of failing to sync the data discrepancies that is caused by a massive amount of tokens. Also, if the data replications between the regions happens to fail, all services in different regions will stop and it would be difficult for us to match the data in the recovery process. Therefore we decided to architect as shown in the next slide.
• #39: Thank’s Park-san. Now I’m going to talk about the relationship between the keystone V2 API domain operation and regions within the OpenStack authentication in Juno. ========= ここからは、JunoのOpenStackの認証基盤のkeystone V2 APIでのDomain運用とRegionの関係について、おはなしします。
• #40: Why? さて、どういうことでしょうか?
• #41: As Park san mentioned, multiple OpenStack clusters are operating in multiple Products within our environment. Primarily this is very inefficient in terms of cloud operation and it is off a principal of a fundamental business rule “selection and concentration”. Starting with the Diablo cluster, we’ve built many OpenStack clusters such as Grizzly, Havana and Juno and they are still in operations. In terms of Swift cluster, we share multiple OpenStack by deploying swift-proxy per Keystone auth. However, it takes a lot of time and cost to deploy OpenStack cluster each time. There is stackforge project called Tricircle that deals with OpenStack deployment across multiple sites but for now, we don’t want to complicate our operation. ========= 先ほどPark sanが話したように、我々の環境では複数のOpenStack clusterが複数のProductで稼働しています。 本来ならば、このようなことは、クラウド運用には無駄が多いですし、ビジネスの「選択と集中」の原則から外れますね。 Diablloのclusterから始まり、 Grizzly、 Havana、 Junoと数多くのOpenStack clusterを構築して、現在もサービスとして運用しています。 Swift clusterはKeystone authごとにswift-proxyを起動することで、複数のOpenStackから共有して利用しています。 しかし、毎回OpenStack cluster環境を構築するのは、工数もかかり大変です。 もちろん、OpenStackをCascadingするProjectでTricircle というのがありますが、いまのところ、より複雑な運用は我々の望むところではありません。
• #42: The cost to operate Multi version Openstack have increased, and it is difficult to upgrade or add new features. Managing multiple sites of OpenStack is a headache for us. ========= ・複数のバージョンのOpenStack clusterを運用する負荷が高くなる。 ・ちょっとしたupgradeや新機能追加もやりにくくなる。 という頭の痛い問題に直面しています。
• #43: It is a dark age for the cloud suppliers ========= クラウド事業者の暗黒面に突入しています。
• #44: Even in that circumstance, we’ve developed a Multi Location environment with OpenStack Juno and launched ConoHa. Speaking of infrastructure features, we’ve deployed features such as DNS and LBaaS. As a keystone feature for IaaS authentication infrastructure, we were able to segment the “by Domain user management” feature. ========= そのような中で、OpenStack JunoでのMulti Location環境を構築してConoHaのサービスを開始したのは先程まで話したとおりです。 インフラの機能としては、DNS, LBaaSなどの機能を盛り込みました。 そのなかでも、IaaS認証基盤のkeystoneの機能として、ドメインによるユーザ管理機能の分割ができるようにしました。
• #45: Motivation is these. ========== Motivationとしては、ドメインにより、スコープをドメイン内に作ることができ、ドメインに属する場合には、 scoped itemsとshared itemsの両方の利用ができるということです。 また、keystone APIはクライアントとサービスのサポートの観点からv2.0を使います。
• #46: Juno Keystone V2 API doesn’t support Domains. We use and customize the code that is in Juno keystone v3 domain. Then we use doamin ID for Juno Keystone v2 API. What you see in the slide is the actual token information in the response JSON. You can see “gnc” as a Domain ID. By doing this you can use Domain ID in token and as long as you write a script based on Domain ID, SaaS we built on top of OpenStack will work just fine. ========== Keystone ver. 2 APIでは、Domainのサポートはありません。 ですが、v3 APIで本来稼働するためのDomain実装ののソースコードが入っていたので、 それを利用して、domain IDをJuno Keystone V2 APIで扱えるようにしました。 右に、実際に keystoneでtokenを取得したときのresponse JSONの中のToken infomationのところを抜き出しています。 Domain IDとして”gnc”が入っていることがわかります。 このようにして、domain_idをtokenでつかえるようになり、OpenStack上に我々が実装したSaaSでもDomain IDに基づいた 処理を書けば動くようになりました。
• #47: There’s one more thing we need to do. In our IaaS case, there is a wrapper proxy for Validation check in the Public API. In Keystone, you determine the Domain either by the prefix of user name and tenant name or by looking up user ID or tenant ID in the keystone DB. Also for other Nova, Glance and Cinder that we want to Scope, we add prefix name. ========== もう一つ、補わなければならないことがあります。 Public APIには、われわれのIaaSの場合、Validation checkのwrapper proxyが入っています。 Keystoneでは、user IDまたはtenant IDをkeystone DBでDomain IDの確認、またはuser name、tenant nameのprefixでDomainを判別します。 Domain IDを判別すると、適切なDomainごとに起動しているKeystoneにAPIがわに、パケットが流れます。 また、ほかのNova, Glance, CinderでもScope化したいものには、同じようにprefix name space をつけることにしています。
• #48: This October, we released our 2nd service on same Juno infrastructure. We added a domain of OEM service for your group company “z.com”. z.com is a brand domain and an OEM partner in Asia that mainly distributes GMO Internet Group companies’ services. 3 regions which includes US, Singapore and Japan is also available with this product. Different domain ids are used for each OEM partners. ============= 10月にConoHaのJuno基盤上に、z.comというグループ企業へのOEMサービスのドメインを追加して、リリースしています。 GMO Internet Groupでもアジアに展開しているグループ会社が、世界に向けてOEM販売するブランドドメインになっています。 このProductでも、先ほどPark sanが説明したUS, SG, JPの3 LocationのRegionが、利用できます。 そのなかで、販売OEMごとに、domain IDがつかわれるようになっています。 =============
• #49: By adding Z.com product, keystone endpoint related to z.com domain is separated in to API endpoint for admin and public API endpoint for users. PaaS and SaaS that we built using Keystone auth is designed to lookup up the Admin URL of this default domain. This is because there is domain ID in the keystone DB and with reverse lookup such as GET token within Admin, there is no issue with using default domain keystone. Also ConoHa and z.com each has a Wrapper proxy program which introduced earlier, in Public API, Internal API and Admin API. ============== Z.comのProductを追加したことで、z.comのドメインに関するkeystone endpointが、adminのAPI endpintとuser用のpublic API endpintがそれぞれつくられています。 我々がKeystone authを使って作ったPaaSやSaaSの サービスはこのDefault domainのAdmin URLを見るようになっています。 これは、Keystone DBにdomain IDが入っているので、GET tokenのようなAdminでのtokenの逆引きでは、Default Domainのkeystoneでも問題ないためです。 また、ConoHa / z.comはそれぞれPublic API, Internal API , admin API の前に、さきほど紹介したWrapper proxy programが入っています。 ==============
• #50: This is Multi-domains and Multi-endpoint details. Left side is named “gnc” domain as ConoHa service. Right side is named “zjp” domain as z.com service. When user access from Internet, connect to the wrapper proxy program by php and nginx system. Validation check to verify the value to OpenStack DB(for example: nova, cinder, neutron or keystone). Then, after passing through the validation check, you can access the real keystone. Other side “zjp” domain is a same scheme, like this, but the different API Value validation and API endpoint. ========== そして、異なるドメインでは、Keystone APIサーバは、ドメインごとに起動する必要があります。 この図の例では、Domain “gnc”とDomain “zjp”では、異なるサービスですので、別々のAPIのEndpoint URLに アクセスすることになります。 アクセス先には、我々が追加で構築したhttps proxyのwrapper serverがあり、ユーザのアクセス情報がそのDomainに属しているのか OpenStack DBに確認して、その後ろの実際のOpenStack APIサーバに渡すようになっています。 この図では、keystone APIですが、wrapper proxyでユーザ名のprefixに”gnc”が付いている場合には、Domain “gnc”では正規のユーザとして、 後ろのkeystone APIに処理を渡します。 Keystone APIが分かれているのは、サービスDomainごとのEndpoint URLのCatalog一覧など、Domainごとに異なる応答をするためです。 Domain “zjp”のユーザがDomain “gnc”にアクセスしても、wrapper proxyがドメインが異なるとして、エラーとして処理します。 ===========
• #51: Here is an our example of how Keystore API servers are set up for each domain. Default Domain ID is a voluntary name and then you use default catalog template file for each regions and set it up the API call. As an END point configuration, this was way more easy to use and has higher versatility. In the IP address section, you would put in the hostname that you registered in DNS for each products. =============== DomainごとのKeystone API serverの設定例を示します。 Default Domain IDとして任意のものを入れて、リージョンごとに、default_catalog.templatesファイルをつかって、API応答するように設定します。 END point登録処理としては、こちらのほうが汎用性と使いやすさがSQLの設定よりあることがわかりました。 上記では、IPアドレスになっていますが、ここをProductごとにDNSに登録したhostnameにします。 ===============
• #52: これらがConoHaで使用しているOpenStackのコンポーネントの一覧です。左の列がOpenStackのコンポーネント名、中央がConoHaのサービス名です。一番右はリージョン名で、一部のコンポーネントは東京リージョンのみに配置しています。
• #55: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #57: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #61: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #68: それでは、GMOインターネットでのOpenStackの使われ方をご説明します。
• #76: That’s all from me. Thanks.
• #77: 最後に、少しエンジニアらしいことを話させて下さい。 私、今回のサミットでビジネスのことや会社のことばかり話しました。 ただ、私は元々アプリケーション開発者です。少しエンジニアっぽいことも話しておくべきでしょう。 この二つはプロビジョニングツールです。上のVagrant、これはVirtualBox、AWS、DigitalOceanなど、いろいろなプラットフォームで自動プロビジョニングを行うものです。エンジニアだけでなくWebデザイナー、アプリ開発者などから非常に多く利用されています。もちろん私も使います。 下の、Docker MachineはDockerホストをプロビジョニングするツールです。最近出てきたもので、まだβです。 この二つにはOpenStackのドライバーやプロバイダーが存在します。ただ、残念ながらConoHaではそのまま動かなかったです。問題となった点は二つ。一つはConoHaがIPv4/IPv6のデュアルスタックに対応していたこと、もう一つはプロバイダーがFixed I1Pに対応していないことです。 自分が使うツールが、自分のクラウドで動かない。これはだめだろう。 VagrantのドライバはFloating IPのみ対応していなくて、Fixed IPに対応していなかったんですね。あと、KeyStoneから返ってくるサービスからログの名前がConoHaとちょっと違っていた。あと他にも細かい問題がいろいろありました。ということで、ForkしてConoHa用のプロバイダーを作って、RubyGemに登録した。いま1000くらいのダウンロードがあります。これでConoHaのインスタンスをvagrant upできる。すばらしい。 Docker Machineの方は、このツールはIpv4 ipv6のデュアルスタックに対応していなかったんですね。ConoHaはデュアルスタックの環境で、docker Machineを走らせるとIP取得の失敗していました。 これはDockerにプルリクエストを送ってマージしてもらえました。次のリリースで入ります。
• #78: ほかにも上のようなWordPressのプラグインなども開発しています。 これはWordPressのストレージバックエンドとしてオブジェクトストレージを使えるようにするプラグインです。 下は、ConoHaの独自APIを操作するCLIツールです。 私はPythonを知らないので、残念ながらOpenStackにコードで貢献することができません。なのでOpenStackのAPIを使ったツールやドライバを、いろいろ書いていきたいと思っています。そうすることで、結果としてConoHaで動作するソフトウェアが増えていくでしょう。