こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」（1/3 ページ） 8月23日に起きたクラウドサービス「AWS」（Amazon Web Services）の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる
2022年6月27日、東京・立川市役所で大規模な通信障害が発生した。出先機関を含めた1000台以上のパソコンで終日、窓口作業ができなくなった。庁内LANの心臓部となるコアスイッチの障害が原因だった。コアスイッチに向けて大量の通信が発生し、メモリー不足に陥った。原因特定に時間がかかり、完全復旧に1週間を要した。 グループウエアの挙動がどうもおかしい――。東京都立川市役所の本庁舎内がざわつき始めたのは2022年6月27日、始業時刻である午前8時半ごろのことだ。ほどなく市役所のITインフラストラクチャー運営を担う総合政策部情報推進課のもとに、「窓口業務用の情報システムにアクセスしづらい」「内線電話が通じなくなった」といった職員らの困惑した声が続々と寄せられるようになった。 情報推進課はただちに障害箇所の特定に乗り出した。庁内ネットワークのメンテナンスを委託している保守事業者と連絡を取り合い、担当
この記事について AWSのDR戦略に関する勉強のアウトプットです。 参考ドキュメント REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する DR戦略 プライマリロケーションでワークロードを実行できなくなった時に、復旧サイトでワークロードに耐えられるようにする。 DR戦略の比較 実装コストがかかるほど、サービスが中断する時間が長くなり、ビジネスへの影響が増えるが、運用コストは安く済む。 運用コストがかかるほど、複雑さは増すが、サービスが中断する時間は短くなり、ビジネスへの影響は少なく済む。 DR戦略の選択 複数リージョンに跨るDR戦略設計では下記いずれかを選択する。 ◆バックアップと復元（数時間でのRPO、24時間以下でのRTO) ■複雑さ：少ない ■コスト：安い ■復旧時間：多い（24時間以下) ■復旧労力：とても多い ＜復旧手順＞ 1.データとアプリケーションを復旧リ
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場
Amazon RDS MySQL/PostgreSQLのトランザクション性能が2倍に、可用性とスケーラビリティも高める新「マルチAZ配置オプション」登場 Amazon Web Servicesは、Amazon RDSのトランザクションの処理速度を最大で2倍にし、3台のクラスタ構成で可用性を高め、リードのスケーラビリティも向上する、新たな「Multi-AZ Deployment Option」（マルチAZ配置オプション）を発表しました。 New AWS News post by @sebsto: New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failoverhttps://t.co/sffr5boYlU — AWS Blogs (@AW
「メインフレームの異常処理」という記事が話題になってましたがとても面白かったです。 qiita.com せっかくなので自分が知ってる範囲で各システムの信頼性における考え方を書いてみました。特にシステムが死んでも仕掛かり中のプロセスが正常完了する事を「無停止システム」としてフォーカスしています。 詳しいわけじゃないからあまり詳しくは話せないので、指摘とか頂けると嬉しいです メインフレーム HPE NonStopサーバ Stratus FT Server オープン系: クラスタ オープン系: 負荷分散(シェアードナッシング) クラウド/仮想環境: Live Migration ソフトウェア: Jakarata EE/EJB ソフトウェア: Oracle RAC ソフトウェア: Erlang/OTP ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン まと
Azure の日本リージョン 7 周年の日に Japan East のストレージ障害が発生するという、なんともアレな出来事がありましたが、障害発生後はアーキテクチャを見直すいい機会だと思うので色々書きます。 まだ RCA は公開されていないですが、おそらくぶちぞう RD がブログに書くのでリンクを貼ります。 4 年前の同じような時期にも Japan East で大規模なストレージ障害が発生したので、同じようなものを書きましたが流石にいろいろと進化しているので古さを感じます。 今回の障害は影響範囲はさほど大きくなかったようで、主に Azure Storage と Virtual Machines がステータスには上がってきていました。実際には Application Insights や Log Analytics にも影響がありましたが、Azure Storage は全ての基本なので仕方な
TIGの伊藤真彦です。 最近会社のPodCastであるFuture Tech Castに出演させていただきました。聞いていただけると嬉しいです。 先日クラウドサービスの障害について社内で体系的に説明する機会があり、0から全体的なイメージがつかめるような情報を整理してみました。 まえがき、良質なクラウドサービスWebサービス、ITソリューションが自前のサーバーではなくクラウドサービスを利用して構築されるようになって久しいですが…と語っていきたい所ですが、私がITの世界に足を踏み入れた時には、既にAWSを使う事が当たり前の時代になっていました、世の中の変遷を語るだけの含蓄を私は持っていません。 私のようにIT技術に触れた瞬間からクラウドサービスが存在していた世代が産まれる程度に長い時間をかけ、AWS、GCP、Azure各種クラウドサービスは業界に浸透し、使いこなすためのノウハウは一朝一夕では身
こんにちは！FIXER R&D Division担当、フェローの千賀です。 今日は、先日8月23日に発生したAWSでの大規模障害を受けて、クラウドを使ってシステムやサービスを構築、提供する際の考え方や留意事項等をお伝えし、止まらないサービスを作るにはどうしたらいいかをアーキテクチャの観点から解説したいと思います。 AWSでの障害の内容と原因 まず簡単に、AWSで2019年8月23日に発生した障害の原因や内容を簡単に解説します。既に当ブログでも取り上げ、報道などもされておりますのでご存知の方も多いかもしれませんが、同日正午過ぎごろから22時過ぎまでの間、AWS東京リージョンにて、EC2やRDSへの接続障害など発生しました。原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバの温度が上がりすぎたことによる過熱である、と報告されています。 これにより約10時間に渡って、AW
「クラウドは信頼できない」は本当か？ AWS、Office 365、自治体IaaSの障害を経て、私たちが知っておくべきこと
「クラウドは信頼できない」は本当か？ AWS、Office 365、自治体IaaSの障害を経て、私たちが知っておくべきこと（1/3 ページ） 2019年は国内外で、大規模なクラウドサービスの障害が相次いで発生した。まず8月にAmazon Web Services（AWS）の東京リージョンで障害が発生し、モバイル決済やオンラインゲームなど多くのサービスが一時利用できない状況に陥った。このAWSの障害による影響状況を目の当たりにし、多くのビジネスがAWSのクラウドインフラに依存していることを思い知らされた。 続いて11月には、米MicrosoftのOffice 365で障害が発生。日本やオーストラリアなどのユーザーはメールの受信が遅れ、復旧に半日ほどを要した。翌20日にも午前中から「Microsoft Teams」や「Skype」などの一部サービスにアクセスできなくなり、Twitter上に「仕
本連載「ポイントを速習！『Azureの基礎（AZ900）』をみんなで学ぶ」では、FIXERの若手エンジニアたちがマイクロソフトの「Azureの基礎（AZ900）」公式ラーニングパスに沿いつつ、Azureを使ううえで覚えておくべき基礎的かつ重要なポイントだけ※をわかりやすくまとめます。実際に手を動かして学ぶハンズオンのコーナーもありますので、皆さんもぜひ一緒に学んでいきましょう。 （※ 本連載はAZ900試験の受験対策を目的としたものではなく、出題範囲すべてを網羅するものではありません） はじめに 連載「ポイントを速習！『Azureの基礎（AZ900）』をみんなで学ぶ」の第4回では、「Microsoft Azure」（以下 Azure）を支えるインフラストラクチャー（インフラ）を紹介したうえで、実際にAzure上で構築したアプリの稼働率を計算してみます。 まず前半では、「リージョン」「可用性
(ベンダーの公式サイト以外での) 日本語によるメインフレーム技術情報は非常に貴重なので、以下の記事は大変興味深く読ませていただいた。 qiita.com で、この記事に付いたコメントで気になる問題提議があったので、連休のヒマに任せて参戦してみる。 Masanori Kusunoki / 楠 正憲 on Twitter: "汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStratusあたりと推察するんだけど、あの手の技術って今に引き継がれてるんだろうか？ / “メインフレームの異常処理 - Qiita” https://t.co/VQtR6lTVuH" 汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStra
皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 これから何回かに分けて、Ansible Tower について書いていきたいと思います。 第1回目は、 Tower を提案する際に良く聞かれる可用性、特に Ansible Tower クラスターについてご紹介したいと思います。 ※なお、この記事は、現時点で最新の、Ansible Tower 3.6.3 をベースに記載しています。 将来のバージョンでは異なる動きとなる可能性もありますのであらかじめご了承ください。 Ansible Tower では可用性を担保する仕組みとして、以下の様な選択肢があります。 クラスター（Active / Active） バックアップリストア Tower オブジェクト自体のコード化 どの仕組みを採用するかは災害発生時に許容される RPO/RTO に依存しますし、そもそも Ansible Tow
【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummit | DevelopersIO
【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummit 本記事はAWS Summit Online Japan 2021で5/11に行われたセッション「【【基本の AWS サービス】マルチリージョン、ちょっとその前に...-サービスの可用性について考える」のセッションレポートとなります。 最近大阪リージョンが開設されたため、マルチリージョンにしよう！と考えている方も多いのではないでしょうか？ぜひ一度本セッションからシステムに必要な可用性について考えてみてください。 セッション概要 スピーカー：アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ISV/SaaSソリューション本部 ソリューションアーキテクト 木村 公哉 日本でも大阪リージョンがフルリージョンとして拡張され、日本国内だけでいわゆる「マルチリージョン」構成を
パブリッククラウドのインフラ障害による影響の重大性 2021年12月9日 翻訳: 島田 麻里子 この記事は米Catchpoint Systems社のブログ記事 Incident Review – AWS Outages Crash Major Online Services – Including Amazonの翻訳です。 Spelldataは、Catchpointの日本代理店です。 この記事は、Catchpoint Systemsの許可を得て、翻訳しています。 以下は、2021年12月8日に発生したAWSの障害では、Amazon Web Servicesの障害についての分析です。 Amazon Web Servicesの障害により、Amazon、Amazon Prime、Amazon Alexa、Venmo、Disney+、Instacart、Roku、Kindle、複数のオンラインゲー
可用性ゾーン、可用性セットは、高可用性を提供するMicrosoft Azureのサービスです。可用性ゾーンとはAzureリージョン内で物理的に独立したゾーン（データセンター）のことで、可用性セットは1つのゾーン内で可用性を高めるための仕組みです。 名称が似ているため混同してしまいがちですが、この2つはそれぞれ異なる意味や役割を持っています。この記事では、まずAzureについて、つぎに可用性ゾーンと可用性セットについて詳しく解説します。 Azure(アジュール)とは？AzureはMicrosoftが提供するクラウドサービスです。世界中に多くのデータセンターを持ち、日本でも西日本と東日本に拠点があります。サーバーやネットワークなどのインフラ環境をクラウド上で提供しており、IoTやAIなど多種多様なサービスも用意されています。ここでは、Azureについて詳しく解説します。 Azureのサービス形
以下に、一部の AWS のサービスが達成目標とする可用性についてまとめます。これらの値は、サービスレベルアグリーメント (SLA) または保証を表すものではなく、各サービスの設計目標に対するインサイトとなるものです。場合によっては、可用性の設計目標に意味のある差異が存在するサービス部分を区別します。このリストは、すべての AWS のサービスを包括するものではありません。また、追加サービスに関する情報で定期的に更新する予定です。Amazon CloudFront、Amazon Route 53、AWS Global Accelerator、および AWS Identity and Access Management コントロールプレーンは、グローバルなサービスを展開しており、これに基づいてコンポーネントの可用性の設計目標が示されます。他のサービスは AWS リージョン内のサービスを提供し、そ
昔起きたALBの障害 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 以前、このような障害が発生しました。 今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。 AZの一部に障害が発生し、 予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。 ALBに障害が発生した事例が多くあったようです。 もしも僕たちのALBが、3AZだったら そんなこんなで 3AZ だったら大丈夫だったんじゃね？とい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
マイクロサービス設計原則: SOLIDではなくIDEALS
立川市役所の庁内LAN障害、原因は「Edgeブラウザーへの移行」
【AWS】DR（災害対策）戦略設計 - Qiita
メインフレーム、無停止サーバ、クラウドにおける信頼性 - ブログなんだよもん
障害に強い Azure の運用を考える (2021 年版) - しばやん雑記
AWSクラウドの耐障害性、可用性を高めるための前提知識 | フューチャー技術ブログ
AzureやAWSの大規模障害でもサービスが停止しない設計とは
Azureのインフラ構成とサービス可用性を高める仕組み (1/3)
Tandem や Stratus の目指した世界は今に引き継がれてるのか？ - cat-a-log
Ansible Tower の可用性 - 赤帽エンジニアブログ
インシデント・レビュー - AWSの障害でAmazonを含む主要なオンラインサービスがクラッシュ | SpeedData
Azureの可用性ゾーンとは？可用性セットの違いや冗長化の方法を解説 | ビジネス継続とITについて考える
付録 A: 一部の AWS のサービスの可用性設計 - 信頼性の柱
ALBを3AZにしてもあの障害は乗り切れないんじゃない？