kubernetes Feed

2017/12/28

IBMでコンテナ化されたクラウドに力を~IBM ITインフラブログより引用~

本記事のIBM社のPower Systems Cloud Offering ManagerのAlise Spence氏によってIBM IT Infrastructure Blogに投稿されたものからの引用です。

原文を参照したい方はPower your containerized cloud with IBMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig348

先月、IBMは新たなオンプレミス用のIBM Cloud Privateを発表しています。

このIBM Cloud Privateについては以下のように表現されています。

An innovative and revolutionary platform-as-a-service (PaaS) offering, IBM Cloud Private incorporates the best of open source tools, including Kubernetes container orchestration, with the unique IBM values that enterprises need to be confident in a secure, compliant and performant private cloud platform.

革新的かつ革命的なプラットフォーム-アズ-ア-サービス(PaaS)製品で、IBM Cloud PrivateはKubernetesのコンテナオーケストレーションを含む最高のオープンソースツールをIBMの付加価値である企業に求められるセキュアでコンプライアンスを満たし、パフォーマンスについても確信を持って利用できるプライベートクラウドプラットフォーム上で動作させることができるようになっています。

IBM Power Systemsをネイティブにサポートしており、競合との差別化は以下のような点があげられます:

  • Developers can create blazing-fast apps by deploying cognitive services on hardware optimized for the work at hand, for higher container density and better throughput.
  • Apps that integrate new cloud-native apps and services with core business data on enterprise systems can be co-located with near-zero latency.
  • Data center administrators can deploy Cloud Private on their choice of Power servers including the IBM Hyperconverged Systems powered by Nutanix, LC servers and enterprise servers with PowerVM.
  • 開発者は高いコンテナの統合率と優れたスループットのためのハードウェアに最適化されたコグニティブサービスを展開することで、非常に高速なアプリケーションを作成することができる
  • 新しいクラウドネイティブなアプリやサービスを統合するアプリケーションとエンタープライズシステムのコアビジネスデータをほとんど遅延のない場所に共存させることができる
  • データセンタ管理者はCloud PrivateをIBM Hyperconverged Systems powered by Nutanix、LCサーバ、そしてPowerVMを搭載したエンタープライズサーバを含むPowerサーバの中から選んで展開することができる

それぞれを詳しく見ていきましょう。。

Want to accelerate the speed of your apps? Our optimized hardware puts you in the driver’s seat with higher container density and better throughput.(アプリのスピードを高速化したい? 最適化されたハードウェアがより高い統合率のコンテナ、より良いスループットへと皆様をお連れいたします。)

A properly configured cloud environment delivers efficiency–a huge benefit to any business, especially when delivered by platform performance. Optimized for cognitive services, Power Systems can deliver insights faster. How? Because of fewer systems and improved horizontal and vertical scalability. The IBM POWER9-based AC922 delivers 3.8 times the reduction in AI model training times[1]. Other Power System servers deliver similar performance gains, all leading to faster and more accurate results for next generation deep learning workloads.

And with multi-architecture support for Docker containers, developers can easily control and automate which platform to deploy specific containers to for best results.

適切に構成されたクラウド環境が効率性を提供します ー あらゆるビジネスにとって巨大なメリットです、特にプラットフォームにパフォーマンスがもたらされた場合には。コグニティブサービスに最適化されたPowerシステムは知見をより高速に提示します。どうやって? 選りすぐったシステムと改善された水平、垂直の拡張性によって、です。IBMのPOWER9ベースのAC922はAIモデルの教育時間を3.8倍も削減することに成功しました(*)。他のPowerシステムサーバも同様のパフォーマンス向上を示しており、全ての次世代のディープラーニングのワークロードをより早く、正確な結果へと導いています。

Dockerコンテナをマルチアーキテクチャでサポートすることで、開発者は最良の結果のためにどのプラットフォームへどのタイプのコンテナを展開するかということを制御、自動化することができます。

Integrate modernized cloud-native apps and services with core business data(コアビジネスデータを最新のクラウドネイティブアプリと統合)

Top enterprises use Power Systems for their most critical business data. Frequently, industry or government regulations are forcing them to find ways to make data more accessible while maintaining their required data security and availability. IBM Cloud Private on IBM Power Systems enables enterprises to create or modernize applications while providing tight integration with the critical data that applications require. By co-locating apps and data, clients will see near-zero latency when integrating with data stores managed in Linux, AIX, or IBM i environments.

トップ企業がそのもっとも重要なビジネスデータのためにPowerシステムを利用しています。よくあることとして業界や当局が標準仕様としてデータに必要なセキュリティと可用性を維持しながら、一方でデータへのアクセス性をより高めるような方法を探すべし、としていることがあります。IBM Powerシステム上のIBM Cloud Privateは企業がアプリケーションが求める重要なビジネスデータの緊密な統合を実現しながら、企業がアプリケーションを作成、もしくは近代化することができるようにします。アプリケーションとデータを同一の場所に格納することで、クライアントからはLinux、AIXもしくはIBM iの環境に管理保管されているデータと連携する際もほぼ遅延のないアクセスを実現することができるのです。

Deploy new cloud native apps on choice of infrastructure, including IBM Hyperconverged Systems powered by Nutanix(IBM Hyperconverged Systems powered by Nutanixを含むインフラストラクチャから新たなクラウドネイティブアプリを展開先を選択できる)

IBM Cloud Private runs across the entire IBM Power Systems portfolio, POWER8 or above, requiring a little endian partition running any flavor of Linux. Clients wishing to leverage existing systems or skills can deploy Cloud Private into PowerVM LPARs. Clients looking to maximize performance for AI or data scientist workloads can opt for bare metal support on OpenPOWER systems. And clients looking to build out new infrastructure in support of new services can get the fastest time-to-value with minimal effort using IBM Hyperconverged Systems powered by Nutanix.

IBM Cloud Private for Power Systems Starter Kits makes it quick and easy to get started. These kits offer implementation guidance that helps organizations to get up and running quickly on their choice of Power Systems infrastructure: OpenPOWER scale-out, enterprise servers, or hyperconverged. When ready, clients can leverage a choice of service-optimized Power Packs, which are Reference Architectures to expand compute capacity and deploy production-ready HA clusters.

Click here to learn more about IBM Cloud Private and try the software, or click here to learn more about cloud solutions like IBM Cloud Private on IBM Power Systems and download a solution brief.

IBM Cloud PrivateはIBM Power システムのPOWER8以降のリトルエンディアンのパーティショニングを稼働させているあらゆるLinuxのすべてのポートフォリオで動作します。既存のシステムを活用する事もできますし、もしくはスキルさえあればCloud PrivateをPowerVM LPARS内に展開することもできます。AIやデータサイエンティストのワークロードの性能を最大化したい場合にはOpenPOWERシステムのサポートの元ベアメタルを利用することもできます。そしてもっとも価値創出までの時間の短い、新しいインフラを最小の労力で作成したいという場合にはIBM Hyperconverged Systems powered by Nutanixをつかうとよいでしょう。

IBM Cloud Private for Power Systems Starter Kitsを利用すれば、素早く、簡単に始めることができます。こうしたキットは実装のガイダンスが記載されており、ご自身の選択したPower システムインフラストラクチャ(OpenPOWERのスケールアウト、エンタープライズサーバ、またはハイパーコンバージド)の稼働開始、稼働の手助けとなります。準備ができたら、サービスに最適化されたPower Packを選び活用することもできます。これにはコンピューティングキャパシティの拡張や本稼働系を展開する際の高可用性クラスタのためのリファレンスアーキテクチャが含まれています。

IBM Cloud Privateについてより詳しく学ぶ、もしくはソフトウェアの試用については こちら をクリック。または こちら をクリックして、IBM Cloud Private on IBM Power Systemsなどのソリューションについて詳しく調べたり、ソリューションブリーフをダウンロードして下さい。

もしもアプリケーションの近代化でどれほどスピードが上がるのかを知りたいのであれば、以下のライブウェブキャストにもご参加下さい :

Bring the Changes Your Customers Want: application modernization and agility with IBM Cloud Private on Power Systems(お客様の要求に変化をもたらす : IBM Cloud Private on Power Systemsでアプリケーションの近代化と俊敏性を)

Time and Date:  11:00 AM EST, January 11, 2018 (日本時間 :2018年11月12日1:00 AM)

Register here. https://event.on24.com/wcc/r/1560084/CF1B4670D48B2BAD72B54C8CD25C8A83

(*) •Results are based IBM Internal Measurements running 1000 iterations of Enlarged GoogleNet model (mini-batch size=5) on Enlarged Imagenet Dataset (2240×2240) .

  • Power AC922; 40 cores (2 x 20c chips), POWER9 with NVLink 2.0; 2.25 GHz, 1024 GB memory, 4xTesla V100 GPU ; Red Hat Enterprise Linux 7.4 for Power Little Endian (POWER9) with CUDA 9.1/ CUDNN 7;. Competitive stack: 2x Xeon E5-2640 v4; 20 cores (2 x 10c chips) /  40 threads; Intel Xeon E5-2640 v4;  2.4 GHz; 1024 GB memory, 4xTesla V100 GPU, Ubuntu 16.04. with CUDA .9.0/ CUDNN 7 .

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

本当は年明けに・・・と思っていたのですが、1月12日の深夜1時からのIBMさんのウェブセミナーの告知も含まれていたので、こんな日にも記事を出しております、ゴメンナサイ。

Nutanix担当の目線でいくと、Nutanix on Powerの上で、IBM Cloud Privateを動作させれば、「Googleのようなウェブスケールなインフラ上でIBMのクラウドが動く」という事になります。重要なデータをAIやコグニティブサービスを使ってビジネスに活用していく、こうした世の中だからこそのプラットフォームだと思います。

2017/12/20

Nutanix Marketplaceはどのように開発者とIT部門を一緒にするのか?

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はHow Nutanix Marketplace Brings Developers and IT Togetherをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

ニースにおいて、我々は新しいエンタープライズのための先進的なパブリッククラウドのような消費モデルの開発者中心のサービスを発表しました。この記事では開発者とITをより緊密にするという我々の見通しを共有させていただきます。そこではよりよいコラボレーションが育まれ、アプリケーションの俊敏性が増すことになります。これによって組織に劇的な効果が上がることになるでしょう。

開発者とITに共通して必要とされる一般的な目的には市場への迅速な投入の加速、対応時間の短縮、インフラストラクチャの問題の解決に費やす時間の最小化などがあります。しかしながら、開発者は最新の技術の取り込みとオンデマンドなリソースの提供に目を向けがちで、IT側はアプリケーション開発者を手助けする適切なツールの必要性についてはしばし目を伏せがちです。Nutanixは既に管理、アップグレード、ITリソースの拡張のシンプル化などの優れたプラットフォームを提供することで市場への投入時間を短くするという部分については提供をしてきています。しかし開発者は本当にサービスの提供についてNutanixプラットフォームを利用していることの価値を感じているのでしょうか?例えば、コンテナの世界に置ける最先端のイノベーションを活用できているでしょうか?開発の業務に集中できるようにするために自動的にコンテナプラットフォームが展開される様になっているでしょうか?ここにNutanix Marketplaceが登場してきた意味があります。

セルフサービスのちからを与える ー ワンクリック、エニークラウド

Nutanix Marketplaceは我々の2017年Q4でのリリースを予定しています。開発者に一箇所からただのワンクリックで必要なアプリケーションリソースを瞬時に利用開始できるようにします。チームにとっては自身のための特別オーダーメイドとなる様々な展開オプションをユーザーの役割とグループに応じて手に入れることができるようになります。Nutanix Marketplaceからアプリケーションの1つを起動するということは、MarketplaceやまたはカスタムのITが事前に作成した、事前に定義された全体が自動化された手順のフローをインスタンス化するということです。これには仮想マシン、バイナリ、必要なアプリケーション構成が含まれています。これを利用することで開発者は自分自身の必要とするスピードで完全にセルフサービスの状態でサービスを利用することができます。

ITの観点からは、単により良く、迅速なサービスを提供できるということだけに留まりません。アプリケーションはマーケットプレイスからいつも実行可能ですし、再現性があり、数日もしくは数ヶ月のアプリケーションの展開や管理の提携作業を取り除くことになります。すべてのユーザーのアクティビティはエンドツーエンドで追跡可能で、トラブルシューティングや互換性のニーズを解決することにも役立ちます。

マーケットプレイスは我々のオープンなアプローチということを前提に設計されています。開発者はアプリケーションをオンプレミスに、もしくはパブリッククラウドにもしくはその両方にまたがっても展開するということを選択することができます。結果としてITはマルチクラウド戦略を実現しながら、その利用状況やクラウドをまたいだリソースのコストについても可視性を手に入れることができるのです。

Fig319

事前統合のBlueprint

開発者は常に新たな開発、検証、コード投入の新しい考え方やツールを取り込むことで開発のプロセスを改善しようと考えています。これを最終目標として、Nutanixは事前に統合され、検証の済んだblueprintを提供し、ITチームが新しいテクノロジーを自身の環境に迅速に導入できるようにします。これらの事前統合されたblueprintを用いることでIT部門は開発者とともに新しいツールを迅速に試験導入し、共同でそれを利用するかどうかの決断をすることができます。この能力は新しいツールの実権を育むということだけではなく、チーム間のコラボレーションを生み出すことにもなります。

上のスクリーンショットではJenkins、Puppet、Hadoop、そしてMySQLなどの事前統合されたblueprintを確認することができます。NutanixはGoogleとのパートナーシップの中でコンテナのオーケストレーションプラットフォームであるKubenetesのblueprintも提供します。このblueprintではNutanixのオンプレミスとパブリッククラウドの両方へKubernetesクラスタを展開することができます。以下のスクリーンショットでは35ページにも及ぶガイドが必要なほど複雑で、多くのコンポーネントと様々なスクリプトが必要になる厄介な手順がシンプルなblueprintへと翻訳され、マーケットプレイスからワンクリックで利用可能になるということを確認できます。

Fig320

まとめると、Nutanix MarketplaceはIT部門に対し、開発者のための優れたセルフサービス環境を実現するための素晴らしい方法をご提供しながら、より良い統制とマルチクラウド戦略への簡単な道筋を提供します。Nutanixでの自動化についてもっとよく知りたいですか? Nutanix CalmのページまたはCalmの技術メモをダウンロードして下さい。

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology, our plans to introduce product features in future releases, product performance, competitive position and potential market opportunities. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, Acropolis Compute Cloud, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

今回もニースで発表になった内容の記事となります。Nutanix Calmはマルチクラウド環境に置けるオーケストレーションを実現するのみならず、スケールアウト、アップグレードなどのアプリケーションライフサイクル全体をコントロールする意欲的なプラットフォームです。

このCalmを最も簡単に利用できるようにするのがこのNutanix Marketplaceです。ワンクリックとある通り、Nutanixの上にこのマーケットプレイスのアプリケーションを展開するのは本当に簡単で、新しい技術を少し試してみようというところから、その先に本格的に導入しようという場合、そしてその環境をパブリッククラウドへと移行させようという場合、様々なライフサイクルの局面で利用することができます。

自動化って・・・開発者のものだよねもしくはDev/Opsだよね、というちょっと大変そうな道ではなく、ワンクリックで簡単な道を用意してくれています。閉ざされた自動化が少しでも開ければと思い、私も期待しています。登場が待ちきれません。(翻訳時には登場が待ちきれませんでしたが、なんとリリースされています!)

2016/08/10

Platform9上にPlatform9を動作させる

本記事の原文:Running Platform9 on Platform9の公開は2015年の2月3日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

僕らも自分のケーキを食べてもいい? 数ヶ月のコンセプトから本稼働環境での利用に至るまでの開発を終えた我々が、自分自身と我々のプライベートなPlatform9 Managed OpenStackのインスタンスに問い続けた質問です。我々はこれを親しみの意味を込めて「ドッグフード」と呼び、日々のビジネス ー継続的な統合と検証ー の大部分で活用しています。

少し前置きを。ご存じの方もおられると思いますが、Platform9はエンタープライズの顧客がご自身のインフラストラクチャのリソースを集約し、柔軟なプールへと変えるようなビジネスをしています。プール化されたインフラは最新鋭のオープンソース・ソフトウェアを利用してPlatform9によって稼働、管理されおり、サービスとして提供されています。マネージドOpenStack、これが我々の最初の製品はこのモデルです。そして、顧客に社内のサーバ、ストレージ、そしてネットワークを利用しながら、完全なOpenStackで構成されたプライベートクラウドを提供します。しかも、複雑なソフトウェアのインストール、構成、拡張、バックアップ、アップグレードは顧客からは見えません。これをどうやって実現する? クラウドのメタデータとコントロールソフトウェアを展開ユニット(Deployment Unit - DU)と呼ばれる要素の集合としてホスティングします。セキュリティのために、それぞれの顧客は自分自身の、完全に隔離されたDUを割当て、それをPlatform9が管理します。

最も単純な形では、DUはデータベースとGlanceとNovaの管理要素(API、スケジューラー、コンダクター、ネットワーク)のOpenStackコントローラーサービス群からなります。顧客のニーズが大きくなるにつれ、DUは複数のサーバーへと拡張することが出来、さらには地理的にも広がっていくことが出来ます。これによってパフォーマンスと可用性を上げていくことが出来ます。簡単のため、この記事では1サーバで構成されたDUにフォーカスします。我々はDUがほとんどあらゆるコンピューティングインフラストラクチャ上で動作するように設計しました。例えばパブリッククラウドや自分自身のデータセンタで動作します。若いソフトウェアカンパニーと同様、我々も必要なコンピューティングを得るためにAmazon Web Services(AWS)を利用することにしました。


  +------------------------------------------------------------------+
  |               展開ユニット (Deployment Unit - DU)                | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  | | PF9コントローラ | | OpenStackコントローラ群 | | データベース | | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  +------------------------------------------------------------------+
            /                              
           /                                
          /          インターネット              
- - - - -/- - - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - -
        /          顧客のイントラネット           
       /                                        
+--------------------------------------------------------+    +----------+
| +------------------------+ +-------------------------+ |    |          |
| | PF9 ホストエージェント | | OpenStackエージェント群 | |    |          |
| +------------------------+ +-------------------------+ |....|          |
|                         ホスト 1                       |    | ホスト N |
+--------------------------------------------------------+    +----------+

多くの近年のクラウドソフトウェアの設計に習い、OpenStackはコントローラ/スレーブのアーキテクチャを採用し、インフラストラクチャの要素を管理・監視します。例えば、コンピューティングホストの管理のため、OpenStack Novaはnova-computeと呼ばえるスレーブエージェントを各管理対象ホストに配置します。最初のManaged OpenStackのリリースでは、ホストはサポートされているLinuxディストリビューション(現在はUbuntu 12とCentOS6 ※訳注原文記事執筆当時の情報です)が動作していればどんなホストでも構いません。コンピューティングキャパシティをプライベートクラウドに追加する際には、顧客はまず、それぞれのホストにゼロコンフィグレーションのPlatform9のホストエージェントを展開します。それぞれのホストエージェントは自身がインストールされているホストをセキュアなアウトバウンド接続を利用して顧客の展開ユニットに登録します。承認(authorization)と呼ばれるステップを通じて承認されると、エージェントはDUに対してホストにとって適切なソフトウェアや構成を問い合わせ、自動的にダウンロードしてインストールし、それらのソフトウェアの構成を行います。特定のホストに適切なソフトウェアの分配を決定する際にはホストにアサインされた役割(role)によって決定します。例えば、普通はコンピューティングホストはnova-computeエージェントを受け取ります。一方で、イメージライブラリホストはPlatform9が特別にパッケージしたソフトウェアを受け取り、それをイメージキャッシングサーバとして利用します。一つのホストが複数のロールを持つことも可能です。まとめると、図1になります。これが通常の顧客の目線から見たManaged OpenStackの展開の様子です。

継続的な統合と検証

Platform9のトッププライオリティは製品を高い品質に保つことです。Managed OpenStack(MO)を検証するため、我々は継続的なビルド&統合サーバ(Teamcity)を用いて、要素/機能検証と統合テストを組み合わせて実施しています。我々は大抵は1つのgitリポジトリを機能コンポーネントごとにメンテナンスしています。Managed OpenStackのリリースのために必要なバイナリを生成する際に、全体で12ほどのリポジトリからのコードのビルドと検証が必要です。リポジトリのうち、いくつかはPlatform9ヴァージョンのOpenStackコンポーネントですし、残りは完全なPlatform9だけのソースコードです。標準のOpenStackのコードは広範な機能検証が含まれており、OpenStackのリポジトリにコードがチェックインする度に検証コードが動作します。

統合テストはもっと複雑で、製品全体を検証し、さらにコンポーネントの展開や接続までを最終形として実施する工程までを含むため、完了までに長い時間がかかります。Managed OpenStackの展開トポロジは通常のOpenStackとは異なっていますので、Platform9固有のシナリオー例えば、ユーザーの認証、ホストの認証、イメージライブラリからのインスタンスの展開、ネットワーク機能、NFSのサポートーでの検証のために多くの統合検証コードをスクラッチから書き起こしました。これを書いている最中にも、17の大きな統合テストが成功に終わることをまっています。上手く行けばManaged OpenStackのビルドがうまくいくということです。それぞれの検証は自分自身で1~15ホストー平均的には大体3ホストーの展開ユニットを作成し、多くの項目に渡る、小さな検証を実施しています。標準では検証用の展開ユニットは1台のコンピューティングインスタンスからなっています。大抵の1つのMOで17の展開ユニットを展開しますので 3 x 17 ~= 50ホストのインスタンスが稼働することになります。ピークの時期になると、CI(継続的な統合)サーバは1日に10回はMOの作成を行います。つまり、170の展開ユニットで500ホストインスタンスを稼働させているということになります。

仮想化環境上に作られた検証インフラストラクチャ

上で述べてきた検証の負荷の推測はあくまで本日(訳注:記事執筆当時)のスナップショットです。もちろん、初期には負荷はずっと軽かったです。他の若い会社と同様に、我々のニーズは最初の一年間で劇的に成長しました、そして、幾つもの失敗の中から多くの教訓を学んだのです。我々の検証のニーズに適合するために、今日我々が検証インスタンスを動作させているインフラストラクチャとその検証を自動化している方法は以下のテーブルにまとめてあるように進化してきました。興味を引くポイントは我々がどのように仮想化を活用し、ソフトウェアのレイヤーを積み上げているかです。

Fig008

フェーズ 1

当初、当然のように我々は検証環境を実際に利用される環境にできるだけ近い形で作成しました。つまり、展開ユニットはAWS上で、Platform9のささやかなデータセンタ内におかれた実際のサーバをコンピューティングホストとして利用します。これはたいていのお客様が経験するであろうセットアップの環境を再現するためでした。このアプローチで我々は2つの問題に突き当たります。一つ目はホストが実際のCentOSまたはUbuntuが動作しているLinuxコンピュータですから、それぞれの結合テストの前に初期状態に復元するためのスクリプトを開発しなくてはならなかったことです。「bit rot(訳注:長時間にわたってコンピュータを使うことでメモリやデータに小さな変化が積み重なり、不安定になること)」と呼ばれる概念をご存知の方もおられると思いますが、これは言うほど簡単なことではありません。様々な努力にもかかわらず、何度もサーバはコントロール不能になり、検証の結果は一環したものにならず、バグを診断するのが難しくなってしまいました。もっと大きな問題は拡張性です : 単純に、我々は増え続ける検証の負荷に見合うだけの十分なハードウェアを購入できない状況になったのです。


   +----------------------------------------------------------+
 2 | 統合検証中に Nova インスタンスが作成される               |
   +----------------------------------------------------------+
 1 | 物理サーバ上の Linux KVM ホスト上のPF9 compute/imagelib  |
   +————————————————————————————————--------------------------+

フェーズ 2

これらの問題を解決するため、我々は以下の表に表したとおり、PF9ホストが動作する検証インフラストラクチャをハイパーバイザー上(最初はESX、そしてその後KVMが動作するネイティブのLinuxへ変更)の仮想マシンへと変更しました。これによって、入れ子になった仮想化が追加されることになります。つまり仮想ハイパーバイザー(2層目)が仮想マシンとして実際のハイパーバイザー(1層目)の上で動作するということです。ESXとKVMはいずれも入れ子の仮想化をある程度の信頼性を持ってサポートしています。(我々はESXがやっぱり素晴らしいということと、ですが、非常にパフォーマンスが限られている場合、KVMのほうが高速で、やっぱりバグや不可解な動きがあることを発見しました。これはこれだけでもう一つ記事が書けそうです。)


   +----------------------------------------------------------------+
 3 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 2 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバ上の ESX または Linux KVM                            |
   +—————————————————————————————————-------------------------------+

我々はPlatform9 Managed OpenStackホスト(2層目)で保持されている仮想マシンの作成や廃棄を担当する機能ライブラリを開発しました。ちょうどこの頃、我々は最初のエンドツーエンドの統合テストの開発を終えました、さらにPythonベースの検証フレームワークの最初のヴァージョンも完成します。社内のTeamcityの統合サーバはコードの変更イベントが発生すればビルドと検証をすべて行ってくれるようになっています。これはコード、ビルド、検証に至るまでエンドツーエンドで自動化統合が完成した時でした。これによって我々はManaged OpenStackの能力を確信もしましたし、品質の期待値を劇的に改善することになります。

フェーズ 3: 「ドッグフード」の誕生

コンポーネントの成熟し、さらに全体がしっかりと結合してくるにつれ、いよいよエンタープライズプロダクトらしくなってきました。我々は適切な機能についてや、適切なユーザーエクスペリエンス、どれだけの信頼性が必要とされるか、セキュリティ、パフォーマンス、拡張性など、数多くの議論を交わしました。終わりのないホワイトボード、ワイヤフレーム、プロトタイプの末に我々は自分たち自身がユーザーにならなければ多くの問題に答えを出すことは出来ないという結論に達しました。言い換えれば、我々の業務(もしくはその大部分)をPlatform9 Managed OpenStack上で行うということです。アメとムチでいうと、これはムチです。

幸運なことに、我々の継続的なビルド、統合、検証にはアメとなりました。我々のごちゃごちゃしているベアメタルのハイパーバイザー(1層目)の上で動作する仮想PF9ホスト(2層目)を管理するためのbashスクリプトやPythonコード群はどんどん複雑化し、維持していくのはまさに悪夢になってきました。我々はテンプレートイメージやホスト間の論理配置、ハイパーバイザーの違い(ESX、CentOS Linux、Ubuntu Linux)に対処出来るだけの綺麗な抽象化を実現していませんでした。こうした問題を解決するためにOpenStackが優れていることは明らかでした。一貫したAPI、CLI、リソースの抽象化、自動配置のアルゴリズムなどが搭載されているからです。

「ドッグフード」プロジェクトはこうして生まれました、そしてこれは今日までに当社がとったエンジニアリングの決断の中で最も大きなものの一つになります。ドッグフードは単にPlatform9 Managed OpenStackの単一のインスタンスです。その展開ユニットは「クラウド」(今はAWS)で動作しており、公開DNSのアドレスでSaaSとして公開されています。全てのコンピューティング、ストレージ、ネットワークリソースはすべてPlatform9のプライベートデータセンタに配置されています。

最初の実装では、我々はPlatform9ハイパーバイザーホストを仮想化していました。会社においてあるハイパーバイザー上で仮想マシンとして動作させていたのです。これは更にスタックに仮想化レイヤを追加することになります。結果は下の図のとおりです。我々はこの追加のレイヤをハードウェアの仮想化サポート機能を完全に利用できるうまい方法を見つけ出すことが出来なかったため、我々は仮想マシン上でQEMUエミュレーションを動作させるしかありませんでした。これはものすごく遅いのです。我々はパフォーマンスが犠牲になるのはわかっていましたが、幾つかの理由でこれを選択しました。まず、仮想(物理の反対という意味で)ドッグフードのハイパーバイザーホストは簡単に作成、管理、廃棄することが出来、それによって必要に応じてホスト数をスケールアップするような操作を簡単に行なえます。2つ目は、このやり方であればすでに持っている稼働率の低いハードウェアを利用できるので、それによって更に物理サーバを追加する際の選択肢も広くなるということです。3つ目は、この時点ではインスタンスを大量に起動する大部分の検証は単にインスタンスがアクティブ状態に到達することを確認するだけのものがほとんどでした。こうした際には検証は早々に終了させることが出来、インスタンスのゲスト内部のスピードはさほど重要ではなかったのです。


   +----------------------------------------------------------------+
 4 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 3 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +----------------------------------------------------------------+
 2 | ドッグフード PF9で管理された仮想の Linux KVM                   |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバで動作する ESX または Linux KVM                      |
   +—————————————————————————————————-------------------------------+

予定通り、我々は自動化のコードを変更してOpenStack Nova APIやCLIを活用できるようにしました。Bashスクリプトは大抵はCLI(nova utilityなど)を利用するために利用されています。そしてPythonコードはRESTをコールする際に利用しています。テンプレートイメージやコンピューティングインスタンスのライフサイクルは一貫した方法で管理できるようになりました。例えば、我々は「刈り込み」というスクリプトを利用して、ビルドの前や、検証の後の時間に古いテンプレートやインスタンスを削除します。様々な理由から、特定のテンプレートやインスタンスを削除せずに保持しておく必要性が出てきます。この機能を実装するため、我々はNovaとGlanceのオブジェクトメタデータにタグを追加し、テンプレートとインスタンスを同じ方法で取り扱うことを実現しました。メタデータのキーに「dont_delete」を追加しておけばよいのです。

フェーズ 4 : ドッグフード 2世代目

ドッグフードの最初の実装はちょっとした統合テストを行えば良いような、会社が小さいタイミングでは充分によく動いてくれました。これはその後の数ヶ月で多くの新しい開発者がチームに入り、多くの機能が追加され、製品の品質を強化するために動作させるビルドや検証の数が爆発的に増えていくにつれ、変わってしまいました。それだけではなく、レイヤ上で動作するQEMUのエミュレーションのパフォーマンスも、もはやインスタンス内のゲストOで動作する興味深い検証などが新しく生まれてきたため、受け入れられなくなってきました。例えば、ほとんどの我々のネットワーク関連の検証はゲストと他のゲスト、または外部システムとの接続を検証します。結果としてOSとして完全にブートが終わるまで待つ必要があります。こうした問題が重なると、ランダムに操作がタイムアウトし、検証に失敗します。これによって我々のエンジニアリングの生産性は地に落ちてしまいました。

我々はパフォーマンスの問題を解決するために、ドッグフードのための専用のハードウェアを購入しました。これによって以下の図のように1つ仮想化レイヤーを削減できました。Linux/KVMをベアメタル(1層目)にインストール、構成しないといけないという柔軟性の喪失は当然のトレードオフです。それを埋め合わせるために、我々はできうる限りのプロセスの自動化を進めました。例えば最初のOSのインストールにはPXEを利用し、Ansibleの構成管理ツールで各ノードに必要なソフトウェア構成を送り込みました。


   +------------------------------------------------------------------+
 3 | 検証中に Nova インスタンスが作成される                           |
   +------------------------------------------------------------------+
 2 | それぞれの検証ごとに PF9 compute/imagelib Linux KVM ホストを作成 |
   +------------------------------------------------------------------+
 1 | ドッグフード PF9 で管理された 物理 Linux KVM サーバ              |
   +————————————————————————————————----------------------------------+

フェーズ 5: ドッグフード 第3世代

ここに至るまで、すべての統合検証環境の展開ユニットは常にパブリッククラウド(AWS)上に展開されています。最初に述べたように、これは実際に利用される環境に可能なかぎり近づけたいという理由からでした。しかし、日々多くの検証のための展開ユニットが生成されるアプローチで、それが100を超えてくると、我々のAWSからの請求書は快適というレベルをあっという間に超えてきました。インスタンスを動作させているというコストからだけでなく、補助的に利用しているEBSストレージ、ネットワーク帯域、RDSデータベースなどからのコストも含まれている結果です。

我々はそれぞれの統合検証が何をしようとしているのかを見直し、殆どの我々の検証はDUが我々のプライベートなインフラストラクチャで動作していたとしてもその価値を失わないという結論に至ります。ですから、我々は検証をAWSではなく、ドッグフード上に展開ユニットを作成するように変換しました。念のためですが、我々はAWSとドッグフードの両方で様々な検証を行っています。我々は徐々に本日我々が利用している構成にシフトしてきました。ドッグフードでは様々な形で我々の日々の継続的なインテグレーションが動作しており、全てのコードのチェックインの度に実行されています。AWSでは定期的に、もっと小規模に実施しています。我々のAWSのためのコストは劇的に下がり、安定しました。しかしながら、ドッグフードを動作させ、適切なハードウェアのリソースを提供し続けるのも時間とお金がかかります。ですから、正確なコスト比較については詳細の分析を待たなければなりません。これが大きな削減になったようなら、またブログの記事を投稿します。

頻繁な更新

ドッグフードは頻繁にアップグレードやアップデートされます。我々のポリシーは実際に顧客のDUへ提供開始する数週間から数ヶ月すべてのコードの変更と昨日の追加を全て展開するというものです。我々はこうした更新を手動で行っています。今後は夜間に自動でアップグレードされるように変更しようと計画しています。

個人利用

加えて、統合検証などで利用するため、我々のプライベートクラウドは各々の従業員向けに個人利用のために開放されています。我々のMacやLinuxマシン上に、novaコマンドラインユーティリティを簡単にインストールし、標準的なOpenStackに接続する環境変数は:


[leb:/devel/pf9-main/testing]$ env|grep OS_
OS_USERNAME=XXXXXXX
OS_PASSWORD=XXXXXXX
OS_AUTH_URL=https://XXXX.platform9.net/keystone/v2.0
OS_TENANT_NAME=service

殆どの開発者は一時的なインスタンスでバグのトラブルシュートや数日で実装できてしまうような機能の開発を行います。他ではもっと長い期間のプロジェクトのために、長時間利用できるインスタンスを作成するか、単に個人の開発環境をホスティングします。我々はOpenStackのタグ機能を利用して、インスタンスやイメージに所有者や目的などの情報についての注釈を入れたりしています。また、頻繁に既存のインスタンスのスナップショットを取っており、試験を動作させる前の状態へと復帰出来るようにしてあります。ユーザーインターフェースについては社内のほとんど半分のユーザーはCLI互換でのアクセスをしていますが、残りの半分は大体はPlatform9のウェブユーザーインターフェイスを利用しているようです。

実体験からの教訓

我々が自分自身のビジネスをPlatform9 Managed OpenStack上で動作させ、ドッグフードを行うと決めた時、とても重要な予見を持っていました。それは、製品に血管があった場合に、我々の会社にすぐにも影響が出てしまうということです。これが我々にとってはトラブルシュート、原因の根本的な解決、問題の迅速な修正についての強いモチベーションになりました。これはまったくもって、予見したとおりでした。製品を日々利用し、ミッションクリティカルなタスクをそれに依存していく中で、我々が検証だけでは様々な理由で見つけられなかった問題を発見することが出来ました。

我々の例は運用が急激にスケールするものです。我々の最初の世代の結合テストでは5ホスト未満でコンピュートインスタンスも1から10インスタンス程度のもので、日々のビルド・検証では数百インスタンス程度の負荷でした。ですが、直ぐに数千インスタンスにも膨れ上がったのです。我々は全てのコンピューティングホストがアイドル状態であっても、それぞれのnova-computeエージェントのサブシステムのうちの幾つかが定期的にNova controllerに状態のアップデート、たとえばKVMの仮想マシンの数やその状態を送るということを知りました。それぞれのこのステータスメッセージはcontrollerに少しずつながら、負荷を加えてゆき、その負荷が充分に大きくなると、公開APIのリクエストの処理をスローダウンさせるということを発見しました。この問題が積み上がっていくと、APIの呼び出しがタイムアウトし、他のビルドタスクの開始に失敗してしまうのです。

他にも、拡張性関連の問題がブートストーム問題の中から燻り出されてきました。上で書いたように、現在製品全体の統合ビルドを行うと、17種類の結合テストが開始されるようになっています。これらのテストは並行して、初期化シーケンスを経て、最終的には50ほどのコンピューティングインスタンスが同時稼働し始めます。我々の統合ビルドサーバは同時に3つのビルドしか同時に走らないように構成されているので、結果としてピークの際には100異常のインスタンスが同時に走ることになります。適切なほどに能力のあるコンピューティングサーバを利用しなかったので、我々はソフトウェアのサブシステムの幾つかが、このスパイクを我々が期待しているほど上手く取り扱うことが出来ないということを発見しました。リクエストがバッチ的に集中する場合、nova-scheduler サービス(インスタンスの配置を決定する)がしばしば同じホスト上に異様に沢山のインスタンスを配置し、リソースを食いつぶしてしまうことがありました。見る限り、ロードバランシングのアルゴリズムがホストの負荷の変化に十分な速さで対応ができていないように見えます。今のところ、これが構成上の問題なのか、設計上の問題なのか追求を進めているという状況です。また、ホストが同時に多くのリクエストを同時に受信するとインスタンスのディスクの処理のための高いCPUとI/Oの負荷の処理で「libguestfs」のサブシステムでタイミングによるバグが出ることも見つけました。これはゲストOSのネットワーク設定を構成する際に利用されます。このバグは修正済みです。

ドッグフードではさほど負荷がかからない、けれども長期にわたって起動し続けるシステムにおいて発生する不具合も見つけ出すことが出来ました。Novaを構成するサービス群は数多くのバックグラウンドタスクを走らせ、メンテナンス用のためのタスクを定期的に活動させます。それぞれのタスクは自分自身でタイマー期間設定を保持しています。あるタスクはその後のタスクの状況に依存している場合があり、その中に長時間に及ぶタイマー設定のタスクがあると数分から、数時間稼働してしまいます。これは時によって非常に見つけにくいバグで発現するのも数日後、しかも特定の状況においてのみ発生するというものです。

不具合や、パフォーマンスの問題を見つける以外にも、日々自身のプロダクトを使うことで製品の至らなさを見つけ、改善することができ、これは我々だけではなく、お客さまにとっても素晴らしい機会となりました。例えば、ウェブインターフェースを利用している時、ある従業員が誤って大きなインスタンスのグループを選択し、それを消してしまうということが有りました。重要なインスタンスがいくつも失われてしまい、こうしたアクシデントが起こらないようにするためにはどうしたらよいか、という議論をすることになります。これに対するソリューションは我々の問題トラッキングシステムの異なるチケットとして様々な形での提案が寄せられます。他と同様に我々は機能追加についてのプライオリティ付を行い、どの製品ヴァージョンでどのリリースを取り込むかを決めます。上で上げた問題では、UIの改善が実装され、ユーザーが大きな破壊操作を行おうとしていることを理解させることが出来るようになりました。最終確認を終え、この変更は既に製品に取り込まれています。製品のAPIレベルで書き込み禁止のフラグを追加で立てるというもっと先進的な改善実装も出来ますが、これは将来のリリースで実装予定です。

将来の方向性

我々はドッグフードの利用範囲を近日中に更に拡張しようと考えています。まずは我々はプロダクトだけでなく、そのワークロードへも拡張しようと考えています。殆どの我々のビルド・統合サーバはベアメタルのハイパーバイザー(ESXとLinux KVM)として動作しており、手動で管理されています。我々はこのミッションクリティカルなシステムを我々自身のプライベートクラウドへと移行させたいと考えています。他の移行候補としてはインフラストラクチャシステムが有ります(例えば、DHCP、DNS、NFS)そして、従業員の個人開発環境などです。

次に、将来のリリースでDockerコンテナのようなLinuxコンテナの管理をサポートする大規模なリリースを予定しています。(訳注:Platform9 Managed Kubernetesとしてリリースされています!)つまり、我々は革新的な方法でコンテナを我々のビジネスに取り入れることが出来るように考えているんです。例としてはまだ検討中ですが、Dockerの大規模スケールでの小さなオーバーヘッドを活用して、何千ものコンピューティングノードのテストを実現したいと考えています。このテクノロジーを利用することで我々のビルドサーバで発生する初期化が不十分であるという問題を解決し、ライフサイクル管理を簡略化したいと考えています。コンテナは常にそれぞれのサーバがクリーンな初期状態で起動することを保証してくれ、しかも高速に起動します。最初のコンテナの管理はマニュアル操作とカスタムのスクリプトで行いますが、直ぐにPlatform9 Managed OpenStackのAPIを利用して出来るようになると思っています。

最後に

自分自身のビジネスをPlatform9 Managed OpenStackで走らせたことは、疑いようもなく我々の製品の改善に役立ちました。日々の面倒な継続的なビルド・検証のシステムをそこへ任せることで、我々は多くの重要な問題を発見し、修正することが出来ましたし、それは人工的な検証シナリオでは見落としてしまうようなものでした。実際の利用シナリオにおける製品の強さと弱さを理解することが出来、そしてユーザーエクスペリエンスと機能の重大なギャップも埋めることが出来ました。これはこの活動の「ケーキ」とも呼べる収穫ですし、そのように意図したとおりとなりました。

この努力によって我々はより俊敏に、そして効率的になったか? 最初の投資コストは正直な話、非常に高いと言わざるをえないものでした。時間、新しいハードウェア、人件費。しかし、今ではシステムが安定し、鼻歌を歌ってくれています。我々はPlatform9 Managed OpenStackが劇的に我々の開発検証の業務を改善し、大規模な自動化を簡単なものにしてくれたと確信することができています。そして、最終的に見ると、今回の努力はパブリッククラウドのためのコストの削減につながりつつ有ります。その通りです、我々は長期の投資の観点から見て危機に脅かされていたのです。このプロジェクトによってそれは解消し、また、我々と我々のお客様のメリットの観点からはより大きな成果を挙げつつあるのです。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/07/07

Container-as-a-Service Platform9 Managed Kubernetes for Docker

本記事の原文の公開は2016年の6月20日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。Platform9関連記事はOpenStack Days Tokyoの終了まで3日間連続で公開予定です。一昨日はKVM昨日はvSphere、本日はKubernetesについての翻訳記事を公開していきます。

Platform9製品詳細についてはこちら

我々がDocker、コンテナー、Kubernetesについて熱狂しているのには2つの理由があります。

完全にマルチクラウドの展開を実現する

過去10年間、(仮想化インフラストラクチャをりようして)完全にマルチクラウドでアプリケーション開発環境を作成することは非常に難しいものでした。これは仮想マシンやゲストOSが本質的にはポータブルとは呼べなかったからに他なりません。例を挙げると、VMware vSphere上の仮想マシンとしてもしくは、Linux/KVM上の仮想マシンとして作成、展開することは非常に簡単です。しかし、一つの仮想化環境から別の環境へとワークロードをシームレスに動かそうとすると? 不可能です。簡単な一回こっきりのプラットフォーム間のインポート作業や、プライベートクラウドからパブリッククラウドへの移行、その反対でさえ、難しいという状態です。

コンテナーは一方、仮想マシン上でも動作します。ベアメタルと同じようにシームレスです。そして、さらに、コンテナーはJVMのようなポータビリティを発揮し、後ろのインフラストラクチャを完全に抽象化する力を持っています。

コンテナーが人気を集めるにつれ、多くのパブリッククラウドプロバイダーは様々なContainer-as-a-Service(CaaS)をそれぞれで提供し始めています。プロバイダーが提供するクラウドプラットフォーム上で、コンテナ化されたアプリケーションをユーザーが利用できるようにするためです。

でも、ポータビリティとは何でしょうか? 本当のコンテナーを利用することのポータビリティのメリットは個々のクラウドプロバイダーがサポートするコンテナーオーケストレーションのフレームワークにロックインされることなく利用ができることです。そうでなければ、クラウドプロバイダーがサポートするフレームワークに縛られてしまうのです。

完全なContainer-as-a-serviceのモデルは、根本的にはマルチクラウド上に展開されるマルチーコンテナーアプリケーションを実現するということになります。そして、エンタープライズのお客さまにとっては、これはプライベートのインフラストラクチャでコンテナをオンプレミスで実行するということで、仮想化状ではなく、ベアメタルで動作させるということを意味します。

Kubernetesによって、このプライベートとパブリック、ベアメタルから仮想化、VMwareからKVMまでの完全な抽象化が実現されます。

優れたクラウドネイティブアプリケーションを簡単に作成できるようにする

我々のエンタープライズの顧客と密に動きながら、我々は彼らがOpenStackを近年のクラウドネイティブアプリケーションを作るための方法の一部として利用しようとしていることに気が付きました。Kubernetesは近年のクラウドネイティブアプリケーションの作成と動作を簡単に(ある意味では、シンプルに)してくれます。Kubernetesはそれ自身でディスカバリやロードバランス、アプリケーションのライフサイクル管理などの機能をネイティブでサポートしているからです。

Platform9 Managed Kubernetes(ベータ)発表

こうした可能性の全てを解決するため、我々はPlatform9 Managed Kubernetesをベータ版として発表致しました。マルチクラウドのビジョンを実現するSaaSで管理されたKubernetes実装です。「Managed」とある通り、Platform9が根本的な部分でKubernetesの展開、構成、そして同左開始後は監視、トラブルシュート、アップグレードなど全てを実施します。ですから、ソフトウェアの開発者はKubernetes APIを利用して、クラウドネイティブアプリケーションの開発にフォーカスすることが出来るのです。DevOps(運用のための開発者)は組織にマルチクラウドの戦略をもたらすことにフォーカスする事ができるようになります。それに加え、企業としては企業が利用するために必要な機能、例えば、ご自身の永続ストレージや、ネットワークテクノロジーとの統合、RBAC(役割ベースのアクセスコントロール)、SSO(シングルサインオン)統合、マルチテナントと隔離などを利用することも出来ます。

また、ついに、Platform9を利用して、仮想マシンの横にコンテナを配置し、全て一貫したユーザーインターフェイスとAPIで統合管理できるようになります。言葉を変えると以下の図のように、仮想マシンをOpenStackを使ってオーケストレーションし、コンテナはKubernetesを利用してオーケストレーション出来るようになったのです。両方がです!

Fig001

この先進的なビジョンと素晴らしいクラウド利用体験を我々のエンタープライズのお客様にお届けできることをこれまでに無く誇らしく思います。是非ベータにお申し込みください!(日本のお客様向けにはこちらのフォームで受け付けております。)

現在どのようにコンテナを利用していますか? 仮想マシンとコンテナをどのようにクラウドネイティブアプリケーションを展開していますか? 是非 @Platform9Sys 又は @madhuramaskasky までお知らせください! (訳注:日本語でのご意見は↓のTwitterでも受け付けております。)

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)