Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
「Google Compute Engine Autoscaler」が正式版に。1000ノードへのスケールが5分以下で実現する高速なオートスケーラー
「Google Compute Engine Autoscaler」が正式版に。1000ノードへのスケールが5分以下で実現する高速なオートスケーラー Googleは、Google Compute Engineで負荷に応じてインスタンス数を増減させるオートスケーラ―「Google Compute Engine Autoscaler」を正式版として公開したと発表しました。 Autoscalerは、2014年11月に発表された機能。これまでベータ版として提供されていました。 最大の特徴は、すでにGoogleのサービスで使われて実績のあるオートスケーラーと同じものをユーザーが利用できるという点で、高いスケーラビリティを備え、ずか数分で千インスタンスを起動するといった、迅速な伸長、縮退が特長。
Amazon VPCとGoogle Compute EngineをVPN接続する | DevelopersIO
ども、大瀧です。 去る3/4にGoogleのIaaSであるGoole Compute EngineのVPNサービスがパブリックベータになりました。AWSのネットワークサービスにあたるAmazon VPCにもVPN機能がありたまたま互換性があったので、それらの相互接続を試してみました。 構成 まずは構成図をどーんと。 と言ってもトンネル1本の構成であれば至ってシンプルで、AWSのVPCとGCEのNetworkをIPsecのVPNトンネルで接続するだけです。GCEのプライベートネットワークは複数リージョンを跨いで構成できますが、現時点ではVPN接続を定義した同じリージョンのVMインスタンスしかVPN接続を利用できないという制限があります。AWSのリージョンとGCEのリージョンを合わせる必要はありません。 費用はGCEはベータ期間中はOutboundの転送料金(GBあたり$0.12)のみ、GA後
GCEのライブマイグレーションのすごさをまとめてみた #gcpja - Qiita
Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事＋個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です！ Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance（自動メンテナンス）という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや
[GCP] クラウドの料金体系を理解する
Google の企業向けソリューションに関する公式な情報やユーザーの事例などを、いち早く皆さんにお届けします。
![[GCP] クラウドの料金体系を理解する](https://cdn-ak-scissors.b.st-hatena.com/image/square/c3089ebaeb6aba6ac4be34fb75379f85ce965e8f/height=288;version=1;width=512/https%3A%2F%2Fblogger.googleusercontent.com%2Fimg%2Fb%2FR29vZ2xl%2FAVvXsEhYb0aFEABDXqoV01RDgSPCUUNhHw0t16iMqQPkgDMtl9mwUH01SInbGq0KgBBLOwddGBKRWvYg_BFC4dnbqoEfT5JbHiB1twlJ2iN_-xxuHFLPspA7LdpNH4SSsL7PxtMs8pDej56FvT9z%2Fs1600%2Fgooglelogo_color_200x200.png)
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用 - Qiita
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用Fluentdgooglecomputeenginekubernetesgooglecloud まずはFluentdコミュニティの皆さん、おめでとうございます！！！ Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです（これは私がいま仕上げ中）。
Google Compute Engineのロードバランサを読み解く#1 #gcpja
ども、takiponeです。 GCE(Google Compute Engine)でVMインスタンスと並んで注目される機能が、ロードバランサ(負荷分散)だと思います。今回から数回に渡ってロードバランサを触り、その特徴をまとめてみたいと思います。 GCEロードバランサの基本 GCEのロードバランサは、2つの独立したサービスがあります。 Network load balancing (L4ロードバランサ) HTTP load balancing (L7ロードバランサ)[Limited Preview] 参考 : Google佐藤さんのQiitaでの紹介 今回は、L4ロードバランサを提供するNetwork Load Balancingを試してみます。 VMインスタンスの準備 まずは、実際に作成して動作を確認します。今回はこちらのエントリーでご紹介した自動構成を利用し、ロードバランサの転送先として
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
Google Cloud Platformをはじめようチュートリアル #gcpja
IaaS的なみかたをすると上記のようなAWSとの比較になりますが、 じつは GAE (Google App Engine)もGCPファミリーのプロジェクトです。 Webコンソールからアカウントをセットアップしてプロジェクト作成 GCEはGoogleのアカウントを使ってログインします。 ログインしたあとにプロジェクトを作成し、 プロジェクトごとに支払情報などを登録します。 ブラウザで利用できるGCPのWebコンソールは https://console.developers.google.com/ にあるのでまずはアクセスします。 お手持ちのgoogleアカウントでログインしましょう。 そうするとプロジェクト一覧の画面になります。 この画面になったら Create Project ボタンを押すとプロジェクト作成ダイアログが表示されます。 PROJECT NAME は自分の好きな名前(今回はSa
Snapchatを支える技術：768台のRedisをGoogleクラウドで構築 #gcpja - Qiita
GoogleのSVP、Urs Hoelzleが「いま世界でもっとも人気のあるスマートフォンアプリ」と評し、Facebookによる3000億円の買収提案をスルーしたとされるSnapchat。その共同設立者でCTOのBobby Murphyが、3/25に開催されたGoogle Cloud Platform Liveに登場し、“Snapchatを支える技術”としてのGoogle Cloud Platform (GCP)の使い所や開発体制をかなり具体的に説明していたので、補足と解説を交えながらざっと意訳してみた。 SnapchatのCTO, Bobby Murphyと、GoogleのSVP, Urs Hoelzle From Google Cloud Platform Live SnapchatがGoogle App Engineを選んだ理由 "それまでいくつかの小さなプロジェクトでGoogle
AWSよりGoogle Compute Engineを選びたくなる10の理由
Google Compute Engineについて興味深いブログがあったので、勉強を兼ねて和訳してみました。 原文はこちらです。 以下、超訳。 昨年（訳注2012年のこと）、GCEとしてGoogleがIaaSの提供を発表した時に、amazonは心配するべきかどうか聞いてみた。18ヶ月後、Google Compute Engineは一般公開され、信頼性、価格、革新性において間違いなくAWSの競合になったと見受けられる。混雑したIaaS市場には多くの新規参入があり、そのいくつかはマイクロソフト、HPとIBMのような十分に確立された企業·ベンダーである。しかし、大多数のそうしたサービス群は限定的な機能しか持たない。彼らはAWSに対抗することは諦め、Amazon EC2の2008年相当のものに見えた。しかし、GCEはそのアプローチからして異なる。Amazon EC2の類似機能に焦点を置くのではなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
