Cloud | SEO-LPO.net

アップルがオープンソース団体Cloud Native Computing Foundationに参加

KubernetesなどのオープンソースプロジェクトのホームであるCloud Native Computing Foundation（CNCF）が今日（米国時間6/11）、Apple（アップル）がトップレベルの会員資格であるプラチナ会員（Platinum End User Member）として参加することを発表した。CNCFのエンドユーザー会員はAdidas、Atlassian、Box、GitHub、The New York Times、Reddit、Spotify、Walmartなど89社いる。

Appleは例によってこの発表に何のコメントもしないが、しかしCNCFによると、エンドユーザー会員とは「オープンソースのクラウドネイティブ技術のヘビーユーザー」である企業や団体であり、コミュニティに対し何らかの還元意思のある者たちだ。CNCFのエンドユーザー会員になると、自動的に上位組織であるLinux Foundationの会員にもなる。

会員になったことによってAppleは、CNCFの統治委員会（Governing Board）にも加わる。具体的に委員として加わるのは、AppleのシニアエンジニアリングマネージャーTomer Doron氏だ。

Cloud Native Computing FoundationのCTO Chris Aniszczyk氏は、こう語っている。「経験豊富な大企業であるAppleがエンドユーザー会員として仲間になったことは、インフラストラクチャとアプリケーション開発の未来にとってクラウドネイティブコンピューティングが持つ生きた力の大きな証（あかし）である。Appleが本会をサポートすることは、たいへんすばらしいし、今ますます大きくなりつつあるクラウドネイティブプロジェクトのコミュニティに今後得られるコントリビューションに、大いに期待したい」。

Appleをメジャーなオープンソース企業と思う人はあまりいないと思うが、実際には同社はDarwinオペレーティングシステムの一部であるXNUカーネルやプログラミング言語のSwiftをオープンソースにしている。オープンソースのクラウドインフラストラクチャコミュニティにはまだ積極的に参加していないが、今日のCNCFへの参加でそれも変わるだろう。当然ながらAppleは、自前のデータセンターを動かしている。しかしそこではきっと、さまざまなオープンソースのインフラストラクチャプロジェクトを多用しているだろう。例によって同社は、それについてもあまり語らないと思うが。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

Google Cloudでリソースの容量能力を予約でき確約利用割引の対象を拡大

Google Cloudが2つの重要な料金改定を行った。ただし残念ながらそれは、よくあるコンピュートとストレージの値下げではなくて、最初のは確約利用割引の拡大だ。GPUsや、Cloud TPU Pods、ローカルSSDなどを一定量、1〜3年契約で利用しているユーザーは、その長期的ロックインの代償として料金がオンデマンド料金の55%引きになる。

もうひとつはCompute Engineの（VMの）容量予約システムで、ユーザーが特定のゾーンにリソースを予約しておくと、あとで本当に必要になったときに確実にそれを使える。

一見すると、容量予約はクラウドらしくないコンセプトだ。なぜならリソースの縮小拡大はランタイムに必要に応じて自動的に為されるはずであり、その可用性をユーザーがいちいち気にするするべきものではない。

では一体、予約システムは何のためにあるのか？Googleの上級プロダクトマネージャーであるManish Dalwadi氏はこう語る。「想定ユースケースは災害復旧やそんなときのための安心感だが、ブラックフライデーやサイバーマンデーのような一時的で特殊な特売イベントのサポートも対象になる」。

つまり、その日には絶対的に必要なリソースが確実に利用できる、ということ。Googleのようなクラウドサービスの大手なら仮想マシンはいくらでもある、と思いがちだが、しかし一部のマシンタイプは特定の可用性ゾーンでないと使えないこともある。仮想マシンというリソースは、その点がその他のリソースとは異なる。

ユーザーは予約をいつでも作ったり取り消したりできるし、既存の割引が自動的に適用される（継続利用割引と確約利用割引）。

確約利用割引に関しては、かなりの柔軟性がある。たとえばユーザーは特定のマシンタイプを3年確約するのではなくて、CPUコアやメモリーなどの数量を確約すればいい。

GoogleのプロダクトディレクターPaul Nash氏は「顧客たちからよく聞くのは、他社の確約モデルには柔軟性がないことと、利用率が60%、70%ととても低いことだ。だからうちの確約割引の設計目標は、自分たちの容量計画を参考にして、ユーザーに十分なお得感があるような割引率にした。気楽に利用できて厳密な管理が要らないことも、目標とした」と説明する。

確約利用割引の拡大と、新たなCompute Engineの容量予約システムは、どちらもGoogle Cloud上ですでに利用できる。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

サーバーレスとコンテナは両者を一緒に使うのがベストプラクティスだ

コンテナに収めたソフトウェアを継続的デリバリ方式で使用するクラウドネイティブモデルは、ランタイムにクラウドベンダーがワークロードを動かすために必要なだけの量のリソースを生成するサーバーレスコンピューティングを利用すると、なお一層有利だ。大手のクラウドベンダーはこのことを知っていて、すでにそのインフラストラクチャを抽象化して隠すプロダクトを作っているが、利点はあるにもかかわらず、どんな状況でも有効とは言えないようだ。

クラウドネイティブは、簡単に言うと、コンテナ化したアプリケーションとKubernetesを使って、ソフトウェアをマイクロサービスと呼ばれる小さなパッケージで配布する。これによってデベロッパーは、継続的デリバリ方式により、ソフトウェアを迅速かつ効率的に配布できる。クラウドネイティブの世界では、コードを開発するのは一度だけ、そしてそれを、オンプレミスでも、どんなパブリッククラウドでもそのまま動かせることが理想だ。

一方サーバーレスは、やや間違った名前だ。このモデルでもコードはサーバーが動かすが、しかしそれは専用の仮想マシンではなく、クラウドのベンダーがワークロードを動かすためにつねに適正な量と時間だけ提供するコンピューティングリソースだ。

万能の完全解はない

このような方式は継続的デリバリモデルによく合ってるようだし、ベンダーもそのことを知っているが、しかしあるエンジニアの言葉を借りれば、そのプロセスは相当複雑であり、また、すべての状況に通用する1つの完全なソリューションはない。

Googleでプロダクト管理を担当しているArpana Sinha氏によれば、Kubernetesのコミュニティはサーバーレスという考え方を本当は歓迎しているのだが、その現在の実装形式に制約がある。つまりAWS LambdaやGoogle Cloud Functions、MicrosoftのAzure Functionsなど現在のの実装形式はいずれも、ファンクションという形式だ。

「ファンクションというコンセプトは制約のあるコンセプトだ。サーバーレスといえばファンクションしか連想しない今の状況は、不幸だ」、と彼女は言う。

彼女によると、Googleはその定義の拡張をトライした。「デベロッパーにとってサーバーレスとは、コーディングからデプロイまでを彼らがシームレスに行い、それ以降のことはすべてインフラストラクチャが面倒見てくれること。黙っていても自分のコードが、インフラストラクチャの適切でもっとも自己回復力のある部分へ確実にデプロイされることだ。必要なリソースは自動的に確保されるからスケーリングも自動化され、スケールダウンも必要に応じて自動的に行われるから無駄な出費がない」と彼女は説明した。

しかしAtlassianのKubernetesチームの上級エンジニアであるMatt Whittington氏に言わせると、理論的にはそれで良くても、実際には完全に自動化されたインフラストラクチャでは現実に合わない場合がある。「デベロッパーがコーディングだけに集中できるからサーバーレスはある種のワークロードにとっては理想的だが、でも完全なソリューションではない。インフラを自分でチューニングしなければならない場合もある」、と彼は言う。

彼によると、ベンダーに完全に任せっきりにできるのは、各コンテナの要求をベンダーに対して指定する方法があるときのみだ。たとえば、コンテナのロードタイムの上限下限をベンダーに指定できるだろうか。ある種のコンテナは時間を食うし、また特定の位置へのデリバリが必要かもしれない。彼によると、実際には完全な自動化はできないし、とくにデベロッパーが設定をいじくって過不足のないリソースが得られるようにしたいときは、自動ではなく手作業になる。

ベンダーも新たな解を提供

これらの問題ではベンダーもツールの提供を始めている。例えばGoogleが先月のGoogle Cloud Nextで発表したサービスGoogle Cloud Runは、オープンソースのKnativeプロジェクトをベースとし、コンテナを動かしているデベロッパーにサーバーレスの長所を結びつける。これと同様のサービスに、AWS FargateとAzure Container Instancesがあり、どちらもやはり2つの技術を1つのパッケージにまとめようとしている。

というかMicrosoftのパートナー事業マネージャーのGabe Monroy氏によると、Azure Container Instancesは、この問題をファンクション型のプログラミング方式に依存せずに解決することが狙いだ。「Azure Container Instancesを使うと、コンテナをAzureのコンピュートファブリックの上で直接動かせる。仮想マシンや、ハイパーバイザーによる隔離、秒単位の課金などはない。私たちはそれをサーバーレスコンテナと呼んでいる」と彼は語る。

サーバーレスとコンテナは相性がとても良いように思えるが、でもMonroy氏が指摘するのは、クラウドネイティブの技術には、すべてに通用する唯一の方式はない、ということだ。AWS LambdaやAzure Functionsのようなファンクション型のサーバーレスを今後も使い続けたい人もいれば、コンテナに移行して二つの技術を一体化したい者もいる。しかしいずれにしても、デベロッパーのニーズが変わっていくにつれて、オープンソースのコミュニティとベンダーの両方が、それらのニーズを助けるツールを提供していかなければならない。サーバーレスとコンテナの一体化も、そんな例のひとつだ。

関連記事: いまさら聞けないコンテナ入門

画像クレジット: Ron Miller/TechCrunch

[原文へ]
（翻訳：iwatani、a.k.a. hiwa）

ZenHubのWorkspacesはGitHubのリポジトリに複数のチーム別ワークスペースを作れる

GitHub用のプロジェクト管理ツールZenHubは、米国時間5月21日、そのサービスをチームで使いやすくするための機能としてWorkspacesのローンチを発表した。それはZenHubのサービスをチームのニーズに合わせてカスタマイズでき、それでも仕事の基盤としてはGitHubを使用するというものだ。

Workspacesはその名のように、チームがGitHubのリポジトリの中に複数のワークスペースを作れる（ZenHubはそのためにChromeのエクステンションを使う）。それによって、あるデベロッパーチームは、すべての問題の詳細なビューを得られ、そのほかのチームは自分たちに関係のあるものだけが見える。このことによってさまざまなチームが、ScrumやKanbanなどなど、それぞれ独自のワークスタイルを採用できる。

ZenHubのファウンダーでCEOのAaron Upright氏はこう語る。「この機能によって各チームが独自の方法で仕事ができ、そのやり方に応じた独自のユニークなワークフローを作れる。例えば、フロントエンドのチームはGitHubの彼ら独自の問題を抱えていて、それらはKanbanスタイルのワークフローになるだろう。またバックエンドのチームなら、独自のScrumスタイルのワークフローになるかもしれない」。

問題は全チームで共有され、どのチームが今何をやってるかもわかる。つまり、社内の透明性が確保される。

画像クレジット: masahiro Makino/Getty Images

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

使いやすくて親切なKubernetesサービスを目指すDigital Oceanはユニークな機能を揃える

クラウドインフラの意欲的なプロバイダーの例にもれずDigital Oceanも最近、そのプラットホーム上でKubernetesのクラスターを動かすための同社独自のソリューションを発表した。バルセロナで行われたKubeCon + CloudNativeCon Europeで同社は米国時間5月20日に、そのプラットホームDigital Ocean Kubernetesが一般公開されたことを発表した。

このリリースで同社はKubernetesの最新リリース(1.14)を提供し、このプラットホームのユーザーには自動パッチによるアップグレードもそのスケジュールとともに提供される。

一般公開に伴いDigital Oceanは、そのサービスを同社の世界中のデータセンターに持ち込み、いくつかの新しい機能も導入する。その中にはたとえば、ガイド付きの構成体験がある。それによりユーザーはクラスターのプロビジョニングからデプロイへ移行する。また健康診断（Health Metrics）と呼ばれる機能により、デベロッパーがクラスターの状態をモニタできる。それには、ポッドのデプロイステータスやCPU、メモリの使用、などのデータが含まれる。

また、サードパーティが自分のソリューションにDigital Ocean Kubernetesのサポートを容易に統合できるための、オープンなAPIも提供する。

さらに同社はもうすぐ、Kubernetes用のワンクリックアプリケーションを集めたマーケットプレースを開店する。Kubernetesのクラスターへアプリケーションをデプロイすることが、それらのツール的アプリケーションでより容易になるだろう。この機能は、すでにKubernetes用のパッケージ管理のデファクトスタンダードであるオープンソースのHelmをベースとする。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

マイクロソフトは2022年までに1万5000名の労働者にAIのスキルと資格証明を賦与

Microsoft（マイクロソフト）は米国時間5月17日朝、同社が教育プロバイダーのGeneral Assemblyと提携して、一定範囲のAI関連スキルの資格証明と教育訓練に投資すると発表した。目標は2022年までに1万5000名を教育訓練して、世界中で多くのAI人材を確保することだ。教育訓練のフォーカスはAIと機械学習、データサイエンス、データエンジニアリングなどに置かれる。

この新事業の初年度には2000名を教育訓練してAIと機械学習のロールに移行させる。そしてその後の3年でさらに1万3000名にAI関連のスキルを教育訓練する。

この取り組みの一環としてMicrosoftは、他社とともにGeneral AssemblyのAIのStandards Board（スタンダード委員会）に加わる。今後の6カ月でこの委員会は、AIスキルのスタンダードを定義し、評価の基準を開発、キャリアのフレームワークを設計、そしてAIスキルの資格証明書を作る。

教育訓練事業は、現在需要のあるAI関連雇用を満たすことにもフォーカスし、そこではMicrosoft固有の技術も学習する。Microsoftによれば、航空宇宙や製造業などいくつかの業種では、Azureを使いこなせるような社員がとても少ない。そこで教育訓練のフォーカスは、AI人材を雇用したいと思っている企業のそのような、Microsoft固有技術のニーズにも対応していく。

また人材ネットワークAI Talent Networkを作り、そこから長期雇用の人材や契約労働者を見つけられるようにする。General Assemblyは、22の大学キャンパスや求人求職サイトAdecco（アデコ）にも縁があるので、この人材ネットワークをアシストできる。Adeccoは昨年General Assemblyが4 億 1300 万ドルで売った企業だ。

Microsoftはこの事業の背景として、雇用創出へのAIのインパクトを挙げている。2022年までには、新しいテクノロジーによって最大 1 億 3300 万の新たなロールが作り出されるそうだ。もちろん、同社のソフトウェアやクラウドの顧客がAzureのような同社製品を使える人々を楽に見つけられるようになるという計算もある。

Microsoftでグローバル営業、マーケティング、オペレーションを担当する執行副社長であるJean-Philippe Courtois氏は声明で「テクノロジー企業がイノベーションにコミットしていくときには、労働者がAIの教育訓練にアクセスできて、今日と明日の職場で伸びていけるようにする責任がある。我々の業態とGeneral Assemblyの専門的技術が組み合わされば、スキルのギャップをなくし、企業はAIに駆動される経済において自らのポテンシャルを最大化できる。その成果が今からとても楽しみだ」と述べている。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

サーバーレスをモニタするEpsagonがAWS Lambdaオンリーを脱して多極化

イスラエルのEpsagonが昨秋ローンチしたときは、サーバーレスのアーキテクチャの中でも特にAWS Lambdaをモニタする意向だった。しかし自分のレパートリーを狭くすることを嫌った同社は米国時間5月7日、もっと多様なマイクロサービス開発方式をモニタしていくと発表した。

CEOで共同ファウンダーのNitzan Shapira氏によると、ローンチしたときはサーバーレスを対象とし、中でもLambdaが最有力のツールと思えた。彼はこう語る。「当時の弊社のプロダクトはLambdaのエコシステムのためにトレーシングやトラブルシューティング、そしてモニタリングを自動化するツールだった。しかしその後、Lambdaに限定されない大きな変化が市場に生じた」。

その変化は、この種のデプロイメントのもっと幅広い視野への移行で、マイクロサービスが関与する一連の現代的なアプリケーションのすべてをカバーするものだ。デベロッパーがそのような現代的で多極的なアプローチに移行すると、単純なエージェントではモニタリングができない。そしてそれでもデベロッパーは、そんなアプリケーションの内部への可視性を必要とする。

Shapira氏によると、そこで同社はこのタイプのモニタリングツールとしては初めて、トレーシングとロギングを一体化したツールをローンチした。彼曰く、「今日では、エンジニアリングとDevOpsがかつてないほど密接に協働している。そこで、マイクロサービスアプリケーションのトレースの自動化をエージェントを使わずに行い、ひとつのプラットホームでトレーシングとロギングを結びつけることが、極めて重要になってきた」。

彼によると、今後の同社の計画は、このようなオープンなトレーシングが複数のツールや複数のフレームワークに対してデフォルトでできるようになることだ。「今はますます、いろんなフレームワークが使われるから、Lambdaだけでなくそれらをすべてサポートすることが必要なんだ」、と彼は言う。

関連記事: Serverless computing could unleash a new startup ecosystem（新しいスタートアップエコシステムを育てるサーバーレスコンピューティング、未訳）

サーバーレスという言葉は、やや誤称だ。サーバーは依然としてあるけど、デベロッパーがそのサーバー上で起動するプログラムを書くのではなくて、クラウドインフラストラクチャのベンダーが、デベロッパーがコードを動かすために必要とするインフラストラクチャリソースを必要なときに、自動的に提供する。

マイクロサービスはこの考え方を利用して、一枚岩的なアプリケーションを構築する代わりに、アプリケーションを一連の小さなサービスに分割し、通常はそれらをコンテナに収めてローンチする。そしてそれらのコンテナをKubernetes のようなツールがオーケストレーションする。

同社は10月にステルスを脱したばかりでまだ新人だが、すでに米国に営業オフィスを置いて4名が常駐している。技術チームはイスラエルにいる。今社員数は、20名に近い。

Shapira氏は顧客数を公表しないが、今のユーザー数は数百社で、有料ユーザーは毎月倍増しているそうだ。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

GoogleのCloud TPU Podsの最新世代はMLモデルの訓練を短時間化

Googleは米国時間5月7日、Cloud TPU Podsの第2世代と第3世代を発表した。このクラウドベースのスケーラブルなスーパーコンピューターは、最大1000基の同社特製のプロセッサ、Tensor Processing Units（TPU）を使用する。それを本日からは公開ベータで一般に利用できる。

最新世代のv3は特に強力で、プロセッサーは水冷されている。一つ一つのポッドが最大で100ペタFLOPSの演算能力を持ち、Googleによれば、世界のスーパーコンピューターの5位以内に入るそうだ。ただし、このTPUポッドはあまり高い演算精度を望めないだろう。

TPU Podは、その全体を使わなくてもいい。Googleはこれらのマシンのスライスをレンタルで提供している。しかし、いずれにしても極めて強力なマシンであり、ResNet-50の標準的な画像分類モデルをImageNetの（100万を超える）画像データセットで訓練する処理を2分で終える。

TPU v2のポッドはコア数が最大512で、v3よりやや遅い。例えば、265基のTPUを使用した場合、v2のポッドはResNet-50のモデルを11.3分で訓練するが、v3ならわずか7.1分だ。ちなみにTPUを1個だけ使うと302分かかるだろう。

当然だが、Googleによればポッドは（料金がどんなに高くても）モデルを早く訓練したいときや、ラベル付きの標本が数百万という大きなデータセットで高い正確性が必要、あるいは新しいモデルのプロトタイプを素早く作りたい、といったユースケースに向いている。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

AWSがクラウドのインフラストラクチャをさらに拡張、AMD EPYCを使うT3aインスタンスを供用開始

Amazonは常に、AWSを使っているデベロッパーに提供するオプションを増やそうとしている。そして米国時間4月25日、同社はそのためにAMD EPYCプロセッサーによるT3aインスタンスを数多く発表した。これらは最初、昨年のデベロッパーカンファレンスre:Inventで発表された。

しかし今日のは、その一般供用の開始を告げる発表だ。それらはバーストのある特殊なタイプのワークロードに適したインスタンスで、ユーザーの通常の計算力のニーズはそんなに、バースト時ほど高くはないというものだ。

AWSのJeff Barr氏がブログにこう書いている。「これらのインスタンスはバーストに対応できる費用効率のいいパフォーマンスを提供し、常時維持されるコンピュートパワーとしてはそれほど高いパワーを必要としないが、使用時に一時的なスパイクがあるワークロードに適している。そのため、十分に余裕のある、確実に保証されたベースラインの処理能力を提供するとともに、さらなる処理能力が必要なときには、必要十分な時間、完全なコアパフォーマンスにまで透明にスケールアップする能力がある」。

これらのインスタンスは、Amazonが数年かけて開発した特製のネットワーキングインタフェイスハードウェアAWS Nitro Systemを使用する。このシステムの主要な部位は、Nitro Card I/O Acceleration、Nitro Security Chip、そしてNitro Hypervisorだ。

今日のリリースの前身として、昨年発表されたArmベースのAWS Graviton Processorsを使用するEC2インスタンスがある。これもまた、スケールアウトするワークロードのためのソリューションを探しているデベロッパー向けのオプションだ。

さらにこの直前の先月には、低コストのAMDチップを使用するM5およびR5インスタンスが発表された。これらもやはり、Nitro Systemを基盤としている。

EPCYプロセッサーは今日から7つのサイズで可利用になり、必要に応じ、ユーザーが選んだスポットインスタンスやリザーブドインスタンス、あるいはオンデマンドインスタンスで提供される。可利用域はUS East（Northern Virginia）、US West（Oregon）、EU（Ireland）、US East（Ohio）、そしてAsia-Pacific（Singapore）だ。

画像クレジット: Thomas Cloer/Flickr CC BY-SA 2.0のライセンスによる

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

メール大好き人間もSlack上のコラボレーションにメールで参加できる

いまなおユーザー数の増加が止まらないSlackが、今週に米国サンフランシスコで行われた同社のカンファレンス「Frontiers Conference」で、いくつかの機能強化を発表した。その中には、Slackの中で同僚とたむろするよりもメールにこだわりたい連中とのコラボレーションがある。

なかなか捨てられない習慣の典型が、ファイル共有やコラボレーションにメールを使うことだ。メールが適しているコミュニケーションもあるが、しかしメールは完全なコミュニケーションツールではない。Slackのような新しいツールがメールを完全に置換することはなくても、メールによるコミュニケーションはけっこう難しい。

しかし、Slackでプロジェクト管理を担当しているAndy Pflaum氏は、メール愛好派と戦うのではなく、メールやカレンダーへのブリッジを作って、彼らがSlackの仲間と、チームの一員として容易にコミュニケーションできるようにした。

彼らはSlackを開いてスレッドを見なくても、使い慣れたメールの受信箱にメッセージが来ている。今月の初めに同社はSlackとOutlookのカレンダーおよびメールとの緊密な統合を発表したし、GmailやGoogle Calendarとの同様の統合も進めている。それは、メールとカレンダーの内容をSlackの中で共有できる仕組みだ。Pflaum氏によると同社は、そのメールやカレンダーとのブリッジを、さらに強化しようとしている。

それによると、Slackのユーザーでない人はSlackのスレッドではなくメールを受け取る。自分がメールで参加しているスレッドへの複数の応答は、ひとつにまとめられてメールで受け取る。ひとつひとつの応答ごとにメールが来ることはない。

そしてメールの中の[Slack]ボタンを押すとSlackが開かれたり、あるいはふつうにメールで応答してそれが自動的にSlackへ行ったりする。Slackが開かれる方式にすると、彼らをメール派からSlack派に転向させられるかもしれない。そんなつもりはない、とPflaum氏は言うけどね。

メールで仕事をしたい人が何人かいるユーザーは、Slackにリクエストするとこれらの機能が有効になる。メールからSlackを開いてリプライする機能も、もうすぐ完成する。[Reply]ボタンでSlackに返事をする機能も、年内に提供される。

関連記事: Slack integration with Office 365 one more step toward total enterprise integration（SlackとOffice 365の統合がさらに前進、未訳）

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

GoogleがGKE Advancedでコンテナサービスをエンタープライズ向けに拡充

Google Cloudは長年、Kubernetes Engine（GKE）でそのプラットホーム上でコンテナを動かすためのマネージドサービスを提供してきた。Kubernetesユーザーのニーズはさまざまだが、でもこれまでのところGoogleはGKEの単一のティアのみを提供し、それは必ずしも、同社が顧客として捉えようとしているハイエンドのエンタープライズユーザーには向いていなかった。しかしながら米国時間4月16日に同社は、新しい機能を数多く備え、SLAに経済的条件を導入し、セキュリティと自動化の機能を高めた、より高度なエディションのGKEであるGKE Advancedを発表した。GKE Advancedはいわば、GKEのエンタープライズバージョンだ。

この新しいサービスは本年の第2四半期にローンチするが、料金はまだ発表されていない。通常のバージョンのGKEは、GKE Standardと呼ばれる。Googleによるとこのサービスは、社内的に何年間も複雑なコンテナインフラストラクチャを動かしてきた経験から学んだことが、ベースになっている。

エンタープライズの顧客にとっては、SLAに経済的条件（SLOが達成されないときの返金制）が盛られていることが嬉しいボーナスだ。ここでの基本的な約束は、リージョナルクラスターの保証可用性（SLO）が99.95%であることだ。

マネージドなKubernetes環境を選んだユーザーの多くは、クラスターを自分で管理する面倒を避けたいからそうしている。しかしGKE Standardでは、クラスターのスケーリングに関してユーザーが一部の作業をしなければならない。そこでGKE AdvancedではVertical Pod Autoscalerと呼ばれるツールがリソースの使用状況をたえずウォッチし、必要に応じてリソースの伸縮を図る。またNode Auto Provisioningツールは、GKE Standardにあるクラスターオートスケーリングの高性能バージョンだ。

GKE Advancedは本体のこれらの機能だけでなく、GKE Sandboxのようなセキュリティ機能も加えている。このサンドボックスは目下ベータだが、GKE Advancedだけにしかない機能になる。そして、コンテナ環境では署名があって検証されたイメージだけしか使われないように強制する。

このサンドボックスは、GoogleのコンテナサンドボックスランタイムgVisorを用いる。これによってどのサンドボックスも自分だけ用のユーザースペースカーネルを取得し、セキュリティの層がひとつ増える。またBinary AuthorizationによってGKE Advancedのユーザーは、すべてのコンテナイメージが信頼された機関によって署名されてからでないとプロダクションに入れられないようにできる。コンテナに悪意あるコードを潜ませることは論理的には可能だが、コンテナのリリースにこのプロセスが課せられることによって、検定され認可されたコンテナのみがその環境で動けるようになる。

GKE AdvancedにはGKEの利用計測機能があるので、社内での利用状況に応じて各部門に課金の適性な分担を求めることもできる。これもやはり、GKE Advancedのみの機能だ。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

Google Cloudがサービスメッシュのためのネットワーキング管理ツール「Traffic Director」を発表

いつも新しいテクノロジーが、新しい用語の一群を引き連れてやってくる。コンテナ化された世界では、アプリケーションは離散的な小片すなわちマイクロサービスに分割される。そんなサービスが増殖すると、サービスメッシュと呼ばれるサービスのネットワークが作られ、その上で彼らは対話する。このような新しいテクノロジーはつねに管理層（マネジメントレイヤ）が必要になり、とくにここではネットワークのアドミニストレーターが新しいコンセプトであるサービスメッシュを理解しコントロールしなければならない。

米国時間4月9日のGoogle Cloud Nextカンファレンスで同社は、オープンなサービスメッシュのためのTraffic Directorのベータを発表した。それはサービスメッシュの中で起きていることの、ネットワークの管理者による理解を助ける。

Google Cloudで技術的インフラストラクチャのエンジニアリングを担当しているヴァイスプレジデントのBrad Calder氏が、このツールを紹介するブログ記事でこう言っている。「サービスメッシュの採用を加速しその管理の苦労を減らすために、Traffic Directorをご紹介できることはきわめて喜ばしい。それはサービスメッシュのためのエンタープライズ対応の構成とトラフィックコントロールのプレーンであり、その上ではグローバルな回復力とインテリジェントなロードバランシング、および、カナリアデプロイメントのような高度なトラフィックコントロールが可能である」。

Traffic Directorは、オペレーションがサービスメッシュを自分たちのネットワーク上にデプロイする方法を提供し、その仕事ぶりやシステムのほかの部分との対話をより強力にコントロールできるようにする。このツールはGCP上のVirtual MachinesやCompute Engineで利用でき、コンテナ化されたアプローチではGCP上のGKE（Google Kubernetes Engine）で使える。

このプロダクトは4月10日の時点でやっとベータだが、そのロードマップには新たなセキュリティ機能とハイブリッド環境のサポート、そして最終的には、昨日同社が紹介したハイブリッド管理ツールAnthosとの統合も行われる。

関連記事: Google’s hybrid cloud platform is coming to AWS and Azure（ハイブリッド環境＆マルチクラウド環境管理ツールAnthosの紹介、未訳）

[原文へ]
（翻訳：iwatani、a.k.a. hiwa）

Google Cloudはクラウドのシェアを伸ばす方法として垂直市場に深入り、まずリテールから

GoogleはAdobeやSalesforceではないが、でもリテイラー（小売業）の要求に見事にフィットするスキルがあり、それによって顧客の体験を良くすることができる。そのスキルの中には、ピーク時でもお店のWebサイトやアプリが確実に動き続けるようにすることも、含まれるだろう。米国時間4月10日のGoogle Cloud Nextカンファレンスで同社は、その垂直戦略（業種別戦略）の例として、複数のソリューションから成るパッケージを紹介した。

また今朝は、同社がSalesforceとのパートナーシップの新たな段階を発表した。それは、コンタクトセンターのAIツールとチャットボットをSalesforceのデータと組み合わせて、両社の長所をより強化し、より良いカスタマーサービスの体験を作り出すプロダクトだ。

しかしGoogleにはSalesforceのような有名企業とのパートナーシップだけでなく、リテイラー向けの独自のサービスもある。それはたとえば、お馴染みのブラックフライデーのような小売店向け販促サービスだ。クラウドの価値がいちばん分かりやすいのは、ブラックフライデーのようなイベントだ。ご存知のようにその日には、サーバーが大量のトラフィックの爆撃に見舞われる。

クラウドは常に、このようなイベントを容易にスケールアップできるが、しかし完全ではない。Amazon は昨年、Prime Dayにサーバーが遅くなった。リテールのウェブサイトが遅くなったりダウンすれば大量の売上を失うから、Googleはそれが起きないように企業を助けたい。

そのために同社は、オンラインのリテイラー専用のサービスeCommerce Hostingを提供する。この特別プログラムでリテイラーは、技術的なレビューやピーク時のオペレーションのサポートなど、行き届いた世話をしてもらえる、という。つまり小売企業のサイトが需要増でダウンしたときでも、損失の大きい惨憺たる結果が生じないようにする。

またGoogleのリアルタイム在庫管理ツールを使えば、店員もお客もどの品番のソックスがあるか、ないかを正確に知ることができる。これもGoogle Contact Center AIと同じく、AIを使っている。Cloud Visionテクノロジーにより、顧客がカメラを商品に向けると、類似製品や関連製品を教える。そしてRecommendations AIは、お客が買った商品の関連商品をおすすめする。

ShopifyやIkeaなども、同社のリテールの顧客だ。またAccentureやCapGemini、DeloitteのようなSIパートナーや、Salesforce、SAP、Tableauのようなソフトウェアパートナーとも協働している。

Googleはこのように多面的なサービスを揃えて、さまざまな垂直市場（業種別市場）に対応しようとしている。それにより、どの業種にも、クラウドのアドバンテージを享受してもらいたい。これが、Google Cloudがソリューションを売っていく新たな方法であり、それによってクラウドのマーケットシェアを増やしたいのだ。

関連記事: Salesforce and Google want to build a smarter customer service experience…SalesforceとGoogleがカスタマーサービスで提携（未訳）

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

API管理サービスのApigeeもハイブリッドのバスに乗り込んできた

今年のGoogle Cloud Nextは、ハイブリッド環境のサポートが大きなテーマだった。だから、同社が2016年に2億6500万ドルで買収したAPI企業Apigeeもまさに、その機に乗ろうとしている。米国時間4月9日、Apigeeはハイブリッド環境向けのプロダクトApigee Hybridのベータを発表した。

長年Oracleにいて最近Google Cloudに来たAmit Zavery氏とNandan Sridhar氏が、共著のブログ記事でこの新製品を説明している。「それはAPI管理プラットホームであるApigeeの新たなデプロイメントオプションであり、それによりユーザーはランタイムをどこででもホストできる。自分のデータセンターでもよいし、あるいはパブリックなクラウドのどれかでもいい」。

今朝Googleが発表したハイブリッド環境管理サービス Anthosと同様に、こちらはAPIをどこで動かしても単一の方法で管理しよう、というものだ（Anthos参考記事（1 ）、（2 ））。

Zavery氏らのブログ記事は、次のように述べている。「Apigee Hybridによって、すべての環境にまたがる単一のそして完全なAPI管理ソリューションが得られる。ユーザーはAPIとそれらが露出するデータをコントロールでき、企業内のすべてのAPIに対する統一的な戦略を確保できる」。

この発表は、多様な環境から成る顧客のコンピューティングシステムをひとつの全体としてサポートしようとするGoogleの全体的な戦略の一環だ。そういう混成環境のことを、昨今はハイブリッドクラウドと呼ぶことが多い。今日のクラウドネイティブの世界では、この考え方は、ユーザーのデプロイメントをそれらがある場所にとらわれずに管理するための、単一のファブリックを提供することに通ずる。

このApigee Hybridも、そんな考え方の延長であり、しかもそれは今やコンテナ化とクラウドネイティブコンピューティングの最前線に位置するオープンソースツールのKubernetes を開発したGoogleにふさわしいやり方だ。ハイブリッドだから純粋にクラウドネイティブではないが、その精神は引き継いでおり、コンピューティング全般に対するGoogle Cloudのアプローチの視界にはしっかりと含まれている。だからこそ、それは、今年このカンファレンスで定義されようとしているのだ。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

Google Cloudの2つの新データセンターがソウルとソルトレイクシティで2020年稼働

米国時間4月9日に開催されたGoogle Cloud Nextで同社は、2020年までに新しいデータセンターを2つ稼働させる。ひとつは韓国のソウル、もうひとつは米国のユタ州ソルトレイクシティである、と発表した。

同社は、他のウェブスケール企業たちと同じく、これまでの数年間、新たなデータセンターの建設に邁進してきた。今では15リージョンが計45ゾーンをホストしている。これにより同社は13カ国にプレゼンスがあり、2016年から2018年にかけては470億ドルという巨額の資本的支出を行ってきた。

Googleのデータセンター（画像提供: Google）

プロダクト管理のディレクターのDominic Preuss氏は、次のように述べた。「韓国ソウルの可用性は2020年の早期に発表できるだろう。これにより、アプリケーションを構築する顧客には3つのゾーンを持つ1つの新しいリージョンが提供される。なお、顧客には、その市場の自分たちの顧客にサービスを提供しようとしている多国籍企業や、グローバル展開を目指している地元企業が含まれる。これによって弊社は彼らのニーズに対応することができ、彼らは自分たちが望むやり方で顧客に奉仕できるようになる」。

さらに付け加えて、「ソルトレイクシティはオレゴンとロサンゼルスに次いで合衆国西部における弊社の第3のリージョンになる。デベロッパーは西部において、複数のリージョンにまたがる分散アプリケーションを構築できるようになる」。

なお、同社の発表では日本の大阪の新しいデータセンターは数週間後に稼働を開始する。インドネシアのジャカルタに建設中のデータセンターは、来年前半に稼働開始の予定だ。

【訳注】上の地図はおかしいので、正しくはこちらをご覧ください。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

企業と社員のアップル製デバイス管理を自動化するFleetsmithが海外進出を目指す

Fleetsmithは2016年に、クラウド上のApple（アップル）製デバイスを管理することをミッションとしてローンチした。同社はAppleのDevice Enrollment Program （日本語ページ）を利用して、これまでは複雑だったITの活動を単純化する。同社は昨年そのサービスを大幅に充実し、そして米国時間4月8日、Menlo VenturesがリードするシリーズBのラウンドで3000万ドルを調達したことを発表した。

Tiger Global ManagementとUpfront Ventures、およびHarrison Metalがこのラウンドに参加した。契約の条件として、MenloのパートナーですNaomi Pilosof Ionita氏が同社の取締役会に加わる。彼女の同僚であるMatt Murphy氏が取締役会のオブザーバーになる。同社発表のデータによると、これで同社の調達総額は4000万ドルあまりになる。

同社の共同創業者でCEOのZack Blum氏によると、最初のミッションは痛点の解消を目指し、共同創業者はAppleのデバイスを管理する現代的なアプローチを手探りで探した。Blumはこう説明する。「Fleetsmithを利用すると、顧客企業はデバイスを社員たちに直接配布できる。そして、それをもらった社員はWi-Fiに接続し、デバイスは自動的に管理システムに登録される」。

彼によると、このような自動化と、同社プロダクトのセキュリティおよびインテリジェンスの機能が合わさって、ITはデバイスの登録やアップデートについて心配する必要がなくなる。社員は、世界中のどこにいてもよい。

最初は主に中小企業に問題解決を提供していたが、最近では規模の大小を問わず、ワークフォースが分散している企業が主な顧客だ。そういう企業にとっては、どこからでも自動的に登録ができるのでとても便利だ。登録が完了したら顧客企業は、会社の全社員にセキュリティアップデートをプッシュしたり、必要ならアップデートを強制できる。ただし社員がクライアントところで会議に出ていることもあるので、そのようなアップデートができない場合には、強力なリマインダーを送る。

昨年同社は、ITが管理下のすべてのデバイスを一望にできるために、ダッシュボードを開発した。それを見ると、個々のデバイスの健康状態や問題点が分かる。たとえば、ディスクの暗号化をやっていないMacBook Proが数台見つかるかもしれない。

このダッシュボードは、Office 365やG Suiteのアイデンティティ管理部位に統合できる。ITはこれら両ツールから直接に社員をダッシュボードへインポートし、すると社員はFleetsmitこれらツールの認証情報でサインインできるから、全社員を管理下に収めることが迅速にできる。

スクリーンショット提供: Fleetsmith

Fleetsmithはまた、Managed Service Providers(MSPs, 各種のマネージドサービスのプロバイダー)とのパートナー事業により、そのリーチをさらに広げた。MSPsは中小企業のITを管理しているから、彼らとの関係を構築すればFleetsmithの拡大も迅速に行える。

現在同社は社員数30名、顧客企業数1500社に成長しているから、このやり方がうまく行ってるようだ。今回の新たな資金は今後のさらなる社員増と、プロダクトの能力拡大、そして海外進出に充てられる（これまでは米国市場のみ）。

画像クレジット: MacFormat Magazine / Getty Images

[原文へ]
（翻訳：iwatani、a.k.a. hiwa）

Google Driveが電子署名や機械学習ツールなど統合して事務処理自動化へ

Googleは米国時間4月3日、ファイル保存サービスDriveに、いくつかの新しいワークフローを統合したことを発表した。それによりこのサービスは、電子署名のDocuSignや、プロセス自動化プラットホームK2とNintexの機能を持つことになる。

これらの新たな統合はどれも一見平凡だが、ユーザーの日常の仕事をすこし楽にしてくれることは確かだろう。DocuSignの統合によって、Google Driveの中でドキュメントを作成、署名、そして保存できるようになる。合意の署名を交わしたら、請求やアカウントのオープン、決済などの事務処理もDriveの中でできる。

K2の統合はやや違って、同社の機械学習ツールにフォーカスする。それによってユーザーは、Googleの機械学習ツールを使って、ワークフロー上でモデルを訓練し、たとえばローンの承認否認判断を自動的に行い、さらにそのローンの申込から承認までに関するすべての情報をGoogle Sheetに保存する。この統合は、Drive内の大量のドキュメントを見つけやすくするなど日常的なユースケースにも対応する。

K2でGoogleとの連携を担当しているバイスプレジデントのEyal Inbar氏は次のように語る。「K2はオンプレミスとクラウドの両方で、ユーザーの情報管理を単純化する。Google Driveとの統合で次世代型のコンテンツ管理サービスを顧客に提供し、彼らが自分のアプリケーションの中で強力なワークフローを構築実装できるようにする」。

Nintexのソリューションはやや専門的で、HRにおける契約管理のライフサイクルを扱う。契約の管理というときわめて地味に聞こえるが、これまた、自動化によって恩恵を得る重要な事務処理のひとつだ。

画像クレジット: Jaap Arriens/NurPhoto via Getty Images/Getty Images

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

メールAPIのMailgunが過半数株をThoma Bravoに売却して再びオーナーチェンジ

メールのAPIを提供しているMailgunが、株式の過半数をプライベート・エクイティ企業Thoma Bravoに売却すると発表した。同社はその条件を公表していないが、これは同社の8年の歴史の中で二度目のオーナーチェンジになる。

Mailgunは、デベロッパーが自分のアプリケーションにメールの機能を組み込むためのAPIを提供している。同社のデータによると、そのAPIを使っている顧客は15万社あまりいる。

投資を発表するブログ記事の中でCEOのWilliam Conwayは、これにより同社はその能力を拡大し、製品開発のスケジュールを早めることができる、と言っている。買収される企業がよく言う言葉だ。

そのブログ記事でConwayはこう述べている。「数百万ドルを製品開発に投じてユーザーの能力を高め、メールに関する多くの知見が得られるようにし、顧客に他に類のない体験を提供できるようにする。またユーザーがアプリケーションに組み込んだメール機能のスケーラビリティを高め、強力で安定的な通信機能をアプリケーションに賦与する」。

同社は2010年に操業し、2011年のY Combinator冬季を受講したが、その後の履歴が複雑だ。2012年にはRackspace に買収され、2017年には単独の非上場企業に戻った。そのときは、別のプライベート・エクイティ企業Turn/Riverが同社に5000 万ドルを投資した。今日の株式売却で、Turn/RiverはMailgunの少数株主として残ることになる。

Mailgunの主な競合他社はMailchimpやSendGridなどだ。Thoma Bravoには、これまで主にエンタープライズソフトウェアの企業を買ってきた履歴がある。いちばん最近では、同社はApttus の過半数株を買った。そのほか同社は、SolarWinds、SailPoint、Blue Point Systemsなどにも投資している。

Thoma Bravoは現時点でコメントの求めに応じていない。

関連記事: Email delivery service Mailgun spins out of Rackspace and raises $50M…MailgunがRackspaceからスピンアウトし5000万ドルを調達（未訳）

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

Webアプリのエラーの原因を早く見つけるLogRocketが12.2億円超を調達

Webサイトで訪問者がトラブルを体験するたびに、その企業の印象が悪くなる。だから、問題はできるだけ早急に解決すべきだ。そのための情報をWebサイトの開発チームに提供する、マサチューセッツ州ケンブリッジのLogRocketは米国時間3月21日、シリーズAで1100万ドル（約12.2億円）を調達したことを発表した。

このラウンドをリードしたのはBattery Venturesで、これにシード投資家のMatrix Partnersが参加した。未発表の400万ドルのシードラウンドを合わせると、同社の調達総額は1500万ドルになる。

創業者のMatthew Arbesfeld氏とBen Edelstein氏は幼なじみで、ともにボストンの郊外で育った。大学はMITとコロンビア大学に分かれたが、その後二人はサンフランシスコに移り、主にフロントエンド専門のエンジニアとして働いた。

LogRocket社のアイデアは、Webアプリケーションのエラーを調べるときの、彼ら自身のフラストレーションから生まれた。問題を見つけるために、手作業による調査をたくさんしなければならない。時間がかかりすぎる。そこから起業のアイデアが生まれた。

Arbesfeld氏はこう説明する: 「LogRocketは、ユーザーのすべてのアクティビティをリアルタイムで記録し、デベロッパーがトラブルシューティングをするとき、それらを正確に再現できるようにする。すると、どこで問題が起きたのかが早くわかるし、対策もしやすい」。

スクリーンショット提供: LogRocket

彼らのツールは、問題を起こしているアクティビティのHTMLとCSSのコードを捕捉し、その部分の操作のビデオも撮る。そしてエラーや問題が生じるとエンジニアはそのビデオを調べて、エラーが生じたとき彼または彼女が何をやっていたのかを見る。このやり方だと、問題の発見と解決がとても早い。

Arbesfeld氏によると、ユーザー体験の全体ではなく問題に関連したコードを捕捉するから、ビデオは本当は必要ない。「ユーザーがトラブった瞬間のコードを見つけて、問題領域にフォーカスできる」と彼は説明する。

ユーザーはそのデータに、LogRocketのダッシュボードからアクセスできる。また、Zendeskのようなヘルプデスクソフトウェアに統合してもよい。同社は今急成長中で、立ち上げから18か月で社員数25名、顧客数500社に成長した。顧客企業の中には、RedditやIkea、Bloombergなどがいる。

今回の資金調達は、彼らにとっては長旅の始まりだ。「顧客層をもっと広げる必要があるし、そのためには有能な営業とマーケティングの組織が必要だ」とArbesfeld氏は語る。「これまでのデータを活用すれば、トラブルが実際に起きてからではなく、前もって問題が起きそうな部分を見つけることもできる」と彼は言う。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

NVIDIAの次世代RTXポッドは1280基のGPU搭載、ネット上のハイエンドビジュアルを狙う

このところNVIDIA（エヌビディア）は、クラウドの大物になりたがっている。もともとは高性能なグラフィクスカードでゲームファンの人気企業だったが、最近ではデータセンターやAI、機械学習の推論、そして推論エンジンやデータ視覚化用のGPUに力を入れている。米国時間3月18日に開催されたGTCカンファレンスで同社は、ハリウッドのスタジオなどビジュアルなコンテンツを迅速に作りたいと願っている企業向けに、RTXサーバーの最新の構成を発表した。

そのRTXサーバーポッドは、32のRTXブレードサーバー上で最大1280基のTuring GPUをサポートする。それはサーバー1つあたり40のGPUを意味し、ひとつのサーバーがEIA規格で8Uのサイズになる。GPUは、構成にもよるがQuadro RTX 4000または6000だ。

今日の発表声明はこう述べている。「NVIDIAのRTX Serversは、Optix RTXレンダリングとゲーム、VR、AR、プロフェッショナルな視覚化アプリケーション向けに最適化されたソフトウェアスタックを持ち、レイトレーシングで強化された映画クラスのグラフィクスを、同じ性能のCPUベースのレンダリングクラスターよりもずっと低いコスト（電気料金）で提供する」。

このパワーを複数のユーザーで共有でき、バックエンドのストレージと相互接続ネットワークは、NVIDIAが今月初めに69億ドルで買収したMellanoxの技術が支える。その買収と今日のニュースはNVIDIAの未来にとってデータセンターがいかに重要であるかを物語っている。

DellやHP、Lenovo、Asus、SupermicroなどのシステムメーカーがRTXサーバーを顧客に提供しており、そのすべてをNVIDIAが検証し、それらの上で動くワークロードの管理には同社提供のソフトウェアツールを使用する。

NVIDIAは、これらのサーバーはARやVRをエッジで動かしたり、5Gネットワーク上でビジュアルをクライアントにサーブするのに適している、と力説している。それはあまりにもバズワードまみれとも感じるし、ARやVRに一般消費者が関心を持ったり、5Gネットワークがメインストリームになるのは、まだかなり先だろう。しかしそれでも、例えばゲームプレーをクラウドからストリーミングで提供するといったニーズには今日すでに、これらのサーバーが活躍できそうだ。

[原文へ]
（翻訳：iwatani、a.k.a. hiwa）