AWSにおける可用性の柱「アベイラビリティゾーン」、この10年の進化とは？ Azureも可用性ゾーンを正式サービスとして開始
AWSにおける可用性の柱「アベイラビリティゾーン」、この10年の進化とは？ Azureも可用性ゾーンを正式サービスとして開始 AWSが高可用性システムのための仕組みとして提供している「アベイラビリティゾーン」は、当初の物理的なシステムの冗長性を実現するという目的から進化してきた。Microsoft Azureも「可用性セット」を正式サービスとして開始したことで、同様の仕組みがクラウドにおける冗長性実現の事実上の標準アーキテクチャになったと言えそうだ。 サーバはいつか必ず故障し、ネットワークもいつか必ず障害を起こします。これはクラウドでも同じことです。そこで、そうした故障が起きたとしてもできるだけ落ちないシステムを構築するための手段としてAWSが提供しているのが「Availability Zones」（アベイラビリティゾーン）です。 アベイラビリティゾーンは、いまから10年前の2008年3月
VMware Cloud on AWSに新機能、vSphereのレベルでAWSの複数アベイラビリティゾーンに対応。既存アプリのままクラウドの高可用性実現
VMwareは、同社がAmazon Web Services（AWS）のクラウドインフラ上で提供するクラウドサービス「VMware Cloud on AWS」の新機能として、インフラレベルで高可用性を実現する「Stretched Clusters for VMware Cloud on AWS」を発表しました。 クラウドで可用性を高めるにはアベイラビリティゾーンへの対応が不可欠 AWSで高可用性を実現するうえで欠かせないのがアベイラビリティゾーンの活用です。アベイラビリティゾーンとは、独立した電源やネットワーク回線を持つデータセンターのこと。一般にAWSのリージョンは高速のネットワークで接続された複数のアベイラビリティゾーンで構成されています。 そして可用性の高いシステムを構築する場合、複数のアベイラビリティゾーンにシステムを分散させ、万が一いずれかのアベイラビリティゾーン内で障害が発生し
Kubernetes 1.9リリース。主要なAPIが正式版に、Windows Serverサポート、コンテナストレージインターフェイスも
Cloud Native Computing Foundationは、コンテナオーケストレーションツール「Kubernetes 1.9」正式版のリリースを発表しました。 Kubernetes 1.9では、コンテナオーケストレーションのための主要なAPI群「apps/v1 Workloads API」が正式版（GA：General Availability）となりました。 正式版となったのは、Webサーバのようなステートレスアプリケーションのクラスタをデプロイする「Deployments」、クラスタの状態を維持する「ReplicaSet」、各ノードに監視用のデーモンなどを設置する構成を行う「DaemonSet」、クラスタ内のノードが落ちたとしても、同一の状態で再起動を行いステートを維持するステートフルアプリケーション用の「StatefulSet」です。 Container Storage I
マイクロソフト、Azureで高可用性を実現する「アベイラビリティゾーン」機能を発表。AWSと同じ仕組み。Microsoft Ignite 2017
マイクロソフト、Azureで高可用性を実現する「アベイラビリティゾーン」機能を発表。AWSと同じ仕組み。Microsoft Ignite 2017 マイクロソフトはMicrosoft Azureで可用性を高める新しい仕組み「Availability Zone」（アベイラビリティゾーン）を発表しました。 Microsoft Azureのブログに投稿された記事「Introducing Azure Availability Zones for resiliency and high availability」では、Availability Zoneが次のように説明されています。 Availability Zones are fault-isolated locations within an Azure region, providing redundant power, cooling, an
米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10％にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
一時的にMulti-AZにしてフェイルオーバーしたRDSのAvailability Zoneを元にもどす一番簡単な方法（TGI Multi-AZ Pattern） - サーバーワークスエンジニアブログ
こんにちは、顔抜きジャーナリストのアカツカです。 私はサーバーワークス東北リージョン担当で、普段はクラウドの恩恵をフルに受けて山形や仙台を中心にリモート勤務をしています。 「クラウドで、東北を、もっと、はたらきやすく。」をモットーに活動しておりますので、どうぞよろしくお願いいたします。 なお、「顔抜きジャーナリスト」が何か知りたい方は、ぜひAWSのユーザーイベントにご参加下さい。 さて、AWSの計画メンテナンスでRDSインスタンスの再起動が行われる場合、別々のデータセンター間で同期レプリケーションされたMulti-AZ構成ではなく、単一拠点でのSingle-AZで運用していると、再起動中はサービスが停止してしまうことがありますよね。 せっかくクラウドを活用しても、これでは可用性の面でオンプレミスの時と変わりありません。 しかしAWSでは一時的にSingle-AZからMulti-AZに切り替
AWS News Blog
AWS Weekly Roundup – AWS AppSync, AWS CodePipeline, Events and More – August 21, 2023 In a few days, I will board a plane towards the south. My tour around Latin America starts. But I won’t be alone in this adventure, you can find some other News Blog authors, like Jeff or Seb, speaking at AWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New – Amazon EC2 H
Amazon RDS for PostgreSQLが正式サービスへ。SLAで可用性99.95％を約束
Amazonクラウドは、昨年11月にベータ版として発表されたPostgreSQLデータベースのマネージ度サービス「Amazon RDS for PostgreSQL」を正式サービスにすることを明らかにしました。 Amazon RDS for PostgreSQLは、データベースのバックアップやレプリケーション、アップグレード、ストレージ管理といった運用をすべてクラウド側で行ってくれるマネージドサービス。 ユーザーは運用に手間をかけることなくデータベースを利用できます。 正式サービスにより、SLAも99.95％と設定されました。ブログ「Amazon RDS PostgreSQL Update - Service Level Agreement and General Availability」から引用します。 The SLA provides for 99.95% availability
押さえておきたいvSphereの基本-可用性編 vSphere DRS
「押さえておきたいvSphere の基本」の可用性編として、2回に分けてvSphereのリソースコントロールの機能と可用性を高める機能のご紹介をしたいと思います。 1回目の今回は、vSphere上でゲストOSを運用する際、特定のESXiホストの負荷が高くなった場合、柔軟なリソースコントロールと稼働ホストの分散により、ゲストOSへの稼働に影響を最小限に抑える機能をご紹介します。 利用ケースとして、複数のESXiホストが稼働している状況で、各ホストのリソースを効率よく活用することにより、ゲストOS間のパフォーマンス劣化を防止することやより高い統合率での仮想環境の運用が可能になります。 その他、サーバリソースを追加した場合、新たに追加されたサーバのリソースの効率的な利用などもあります。 仮想マシンが増えてきた場合、それらの仮想マシンの負荷を想定して、どのサーバー上で稼働させればパフォーマンス最適
CAPの定理と分散データベースの話 - プログラマでありたい
前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。 共用セッションストアの格納先を分散データベースにすれば良いよ セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基本姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。 CAPの定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[和訳] Chef Serverの高可用性とレプリケーション #opschef_ja #getchef_ja - クリエーションライン株式会社![[和訳] Chef Serverの高可用性とレプリケーション #opschef_ja #getchef_ja - クリエーションライン株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/271da196112dceefc48eab04819bd722ff406139/height=288;version=1;width=512/https%3A%2F%2Fwww.creationline.com%2Ftech-blog%2Fcms_x3GWkuX%2Fwp-content%2Fuploads%2F2014%2F11%2Fchef_server_ha_aws.png)