Google CloudでMemcachedが使えるようになった

GoogleはこのほどMemorystore for Memcachedのベータ版を公開した。GoogleのMemorystoreサービスは高速性が必要とされる大規模データベースなどをクラウドのインメモリで作動させるのに適しているが、ここでMemcachedがフルマネージドで利用できるようになった。これは複数サーバのメモリを統合して利用するためのオープンソースのプロトコルで、2018年にGoogleがスタートさせたRedis向けインメモリデータストアサービスに含まれることになる。

米国時間4月3日の発表でMemorystoreのプロダクトマネージャー、Gopal Ashok(ゴパル・アショク)氏は「Redisは今後もセッションストア、ゲームのリーダーボード、ストリーミング分析、マルウェアの脅威検出、APIレート制限などのユースケースで引き続き人気ある選択肢だろう。現在、Memcachedはデータベースのキャッシュのレイヤーとして頻繁に利用されている。デベロッパーはMemcachedをセッションストアにもよく用いている。我々の新サービスを利用すれば、インスタンスごとにメモリのクラスターのサイズを最大を5TBまで拡張できる」と述べている。

このサービスは名称のとおり、オープンソースのMemcachedと完全に互換性がある。従ってデベロッパーはコードに手を加えることなくMemcachedプロトコルを利用した既存のアプリケーションをGoogle CloudのMemechacedプラットフォームで運用することができる。

フルマネージドサービスなので作動のモニタ、パッチの適用などの定型業務はすべてGoogleが処理する。最大キャッシュサイズを決める部分にはやや職人技が残るが、Google Cloudでは「詳細な統計を提供するのでデベロッパーはインスタンスの大きさを上下させ、実行するユースケースに対して最適なキャッシュサイズを容易に設定できる」としている。Googleが提供するモニタ情報は Cloud Monitoringによって測定される。これはGoogle Cloudの中心的ダッシュボードであると同時にAWSの動作も計測できるという。

現在、Memorystore for Memcachedは Compute Engine、Google Kubernetes Engine(GKE)、App Engine Flex、App Engine Standard、Cloud Functionsで実行されるアプリケーションに使用できる。

Memcachedの利用に関しては、AWSがElastiCache for Memcachedで同種のサービスを提供している。またMemCachierなどこのプラットフォームの利用を専門とするスタートアップがある。Redis Labsも、フルマネージドのMemcachedサービス、Memcached Cloudを提供している。このサービスはAWS、Azure、Google Cloudで実行できる。

画像クレジット:Krisztian Bocsi/Bloomberg/Getty Images(Googleのベルリンオフィス)

原文へ

(翻訳:滑川海彦@Facebook

GoogleのKubernetes Engineが3種のリリースチャネルとWindows Containerをサポート

2年に一度行われるクラウドネイティブのカンファレンスKubeCon+CloudNativeConでGoogle(グーグル)は米国時間5月20日、Google Kuberentes Engine(GKE)の3つのリリースチャネル、RapidとRagularをStableを発表した。

これによりGoogle Cloudのユーザーは、最新のリリースを選ぶか、それともいちばん安定したやつで行くかなどを選択でき、また最新のアップデートを開発環境の中で容易に評価できる。このリリースチャネル機能は、目下アルファテストの段階だ。

Googleのリリースノートには「各チャネルで、成熟度と鮮度が異なる。デベロッパーはリスクの許容度とビジネスの要求のあいだで適正なバランスを取りながらクラスターをアップデートのストリームにサブスクライブできる」と書かれている。

今アルファで提供されているのはRapidチャネルの最初のリリースで、それがデベロッパーにKubernetesの最新バージョンのアーリーアクセスを与える。

Rapidへのリリースとともに、GoogleはまたGKEによるWindows Containersの初期的サポートを提供する。最近の何回かのリリースの過程でKubernetesのコミュニティはWindowsサポートを徐々に改良し、そして今度はGoogleが6月にWindows Server Containersのサポートを提供する。

これらの機能に加えてさらに、同社はKubernetesをモニタリングするStackdriverツールをリリース。このツールでGKEのモニタリングとロギングができ、また他のクラウドやオンプレミスのインフラストラクチャでのKubernetesのデプロイにも対応できる。

画像クレジット: Alija

[原文へ]

(翻訳: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がIstioをGKEに統合、いよいよスタンダードツールの仲間入り

Googleが今日(米国時間12/11)、GKE、Google Kubernetes Engineのアップデートを発表し、それによりこのサービスに、Istioサービスメッシュのサポートが統合される。Istioのサポートは、現在ベータである。

Istioはまだ、Kubernetesが近年そうなったような高い知名度の用語ではないが、多くのエンタープライズにとって、クラウドネイティブなプラットホームを構築するための重要なビルディングブロックになっている。

Istioの中核的な機能は、Kubernetesをはじめさまざまなプラットホーム上で複数のマイクロサービスを互いに接続し、モニタし、セキュリティを図るためのオープンソースのサービスメッシュ〔mesh, 網の目〕だ。IstioとそのEnvoyプロキシなどのサブコンポーネントは、複数のマイクロサービスを統合し、それらのセキュリティを図り、ログデータを集積し、それらにより、Kubernetesのようなオーケストレーションのレイヤ(層)の上に新たな抽象化レイヤを提供する。

Google CloudのChen GoldbergとJennifer Linが、今日の発表でこう述べている: “Istioはマイクロサービスをもっとも有効に利用するための重要な役割を担う、と堅く信じている。そのためのIstioのやり方は、優れた可視性とセキュリティを提供することによって、コンテナ化されたワークロードをより容易に扱えるようにすることだ。このたびIstioがGKEに統合されたことによって、われわれはメジャーなクラウドプロバイダーとしては初めて、Kubernetesサービスとのダイレクトな統合を提供し、コンテナのライフサイクル管理を単純化した”。

GoldbergとLinはさらに強調して、Istioによってデベロッパーとオペレーターはアプリケーションをサービスとして管理でき、大量のさまざまなインフラストラクチャレベルの部位を見る・扱う必要がなくなる、という。また彼らによると、Istioを使うとネットワークトラフィックのすべてを暗号化できる。当然のようにGKE上のIstioには、Google CloudのモニタリングとロギングサービスStackdriverが統合されている。

Istioは、2017年の半ばにローンチした。そのプロジェクトは、GoogleとIBMとLyftのコラボレーションの産物だ。今夏7月にバージョン1.0に達し、Datadog, SolarWindsなどの企業がその後、自分たちのサービスにそれを統合するためのプラグインを作った。Cloud Foundryプロジェクトも、それをその、新しいトラフィックルーティングスタックのコアとして使い、Istioをサービスの中核としている。

関連記事: マイクロサービスの集まり(単一/複数アプリケーション)を安全に管理するプラットホームIstioをGoogleとIBMとLyftが共同で立ち上げ

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitLabがGoogleのKubernetes Engineを統合、コンテナアプリケーションのデプロイが超簡単に

今や多くの人が使っているVCSのGitを、独自にホストしているサービスとして人気の高いGitLabが、最近とくに好調だ。わずか2週間前にはGitHubとの統合を発表したが、今日はGoogleのKubernetes Engine(GKE)を統合してクラスターの展開を自動化し、ユーザーであるデベロッパーが自分のアプリケーションをほんの数クリックでデプロイできるようにした。

この機能を作るために同社はGoogleと協働したが、しかしこの統合はGitLabに前からあるAuto DevOpsツールを大々的に使っている。それは、コンテナを扱うためのよく似た機能をすでに提供していた。Auto DevOpsは、CI/CDパイプラインのセットアップやコンテナへのデプロイなど、面倒な仕事をすべて引き受けることをねらっている。

しかし、“GKEを統合する前は、GitLabのユーザーは自分のクラスターを管理するためにKubernetesの深い理解を必要とした”、とGitLabのCEO Sid Sijbrandijは今日の発表で述べている。“Googleとの協働により、われわれのユーザーはGoogle Cloud Platform上に、管理サービスを伴うデプロイ環境をセットアップし、GitLabの堅牢なAuto DevOpsの能力を利用することが簡単になった”。

このGKEの統合を利用するためには、デベロッパーはGitLabから自分のGoogleアカウントに入るだけだ。GKEがクラスターを自動的に管理するので、デベロッパーは自分のアプリケーションを書くことに集中でき、デプロイと管理はGitLabとGoogleにまかせられる。

この新しい機能はGitLab 10.6 releaseの一部として、GitLabの全ユーザーが今すでに利用できる。

〔この記事の日本語訳。〕

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa