こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
https://sre-lounge.connpass.com/event/227250/
※この投稿は米国時間 2021 年 5 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。 アプリケーションの可用性を確保するために重要なのは、サービスレベルの指標を確立してモニタリングすることです。これは、サイト信頼性エンジニアリング（SRE）チームが Google Cloud で毎日実施している内容です。SRE 原則の最終目標はサービスを改善し、さらにユーザー エクスペリエンスを向上させることです。 SRE の概念は、指標がビジネスの目標と密接に結び付いたものであるべきだという考えから始まりました。ビジネスレベルの SLA に加えて、SRE の計画と実践に SLO や SLI も使用します。 サイト信頼性エンジニアリングの用語を定義するこうしたツールは、単なる便利な抽象概念ではありません。これらのツールがなければ、システムの信頼性、可用性、有用性は評価できま
本連載「ポイントを速習！『Azureの基礎（AZ900）』をみんなで学ぶ」では、FIXERの若手エンジニアたちがマイクロソフトの「Azureの基礎（AZ900）」公式ラーニングパスに沿いつつ、Azureを使ううえで覚えておくべき基礎的かつ重要なポイントだけ※をわかりやすくまとめます。実際に手を動かして学ぶハンズオンのコーナーもありますので、皆さんもぜひ一緒に学んでいきましょう。 （※ 本連載はAZ900試験の受験対策を目的としたものではなく、出題範囲すべてを網羅するものではありません） はじめに 連載「ポイントを速習！『Azureの基礎（AZ900）』をみんなで学ぶ」の第4回では、「Microsoft Azure」（以下 Azure）を支えるインフラストラクチャー（インフラ）を紹介したうえで、実際にAzure上で構築したアプリの稼働率を計算してみます。 まず前半では、「リージョン」「可用性
untitled
IT IT IT IT 1 IT 2 Software as a Service (SaaS3) IT SaaS 4 SaaS SaaS PC SaaS SaaS Web SaaS ID IT SaaS IT 1 2 3 Software as a Service ASP(Application Service Provider) SaaS 4 ASPIC SaaS SaaS SaaS SaaS ASP IPA SaaS SaaS IT IT SaaS SaaS ASP i 1. ····································································- 1 - 1.1. ······························································- 2 - 2. SaaS ··
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。 AWS 上にシステムを構築する際の可用性設計について考えてみます。 可用性の定義は幅広いですが「サービスが利用できている時間の割合」として今回は考えます。 AWS の SLA AWS は SLA を公開しています。英語版が最新なので言語を English にしてご覧ください。 AWS Service Level Agreements サービスごとに定義された稼働率を実現するように AWS が商業的な努力を払い それを満たさない場合に契約者はサービスクレジットを受け取る権利があります。 AWS が公開しているベストプラクティスに従った構成が必要といった前提や 除外事項がサービスごとに定義されていますのでご確認ください。 更新日は少々前
IT 運用、開発、ビジネスの各チームのためのサービス管理 大規模でベロシティの高いサービス管理を提供します。
Webサイトのアップタイムやパフォーマンスを向上させるソリューションを提供するUptime.comは、2021年2月19日（米国時間）に公式ブログで、SLA（サービスレベル契約）に関する誤解について解説した。SLAについて誤った考えを抱いていると、DevOps業務に悪影響を与える場合があるという。DevOps担当者向けに7つの一般的な誤解を取り上げ、どこが間違っているのかを解説した。 誤解1 1つの開発言語を使うべきだ DevOpsを適切に進めるには、複数のツールが必要だ。作業に応じて適切なツールを使う必要があり、使用する言語を1つに絞るべきではない。 PythonやJavaScriptは多種多様な目的に使えるが、決して唯一の選択肢ではない。 誤解2 100％のアップタイムは達成可能で、持続可能でもある この誤解は、今回取り上げた中で最も有害な誤解だろう。この誤解のせいで、非現実的なSLA
$60\times 60\times 24\times 365=31536000$ です。（うるう秒とかうるう年とかは考えません） 稼働率99％は高くない 実際、停止時間は、 $31536000\times 0.01=315360$ 秒で、 $315360\div 3600=87.6$ となります。 １ヶ月あたり $7.3$ 時間停止することに相当します。 稼働率 $99$％は一見高そうに見えますが、毎月 $7$ 時間以上停止するシステムやサーバの信頼性が高いとは言いづらいですね。 より高い稼働率だとどうか 稼働率 $99.5$％ ・年間で $43.8$ 時間停止することに相当 ・月間で $3.65$ 時間停止することに相当 稼働率 $99.9$％ ・年間で $8.76$ 時間停止することに相当 ・月間で $43.8$ 分停止することに相当 稼働率 $99.95$％ ・年間で $4.38$
Are you responsible for a customer-facing service? If you are, you know that when that service is unavailable, it can impact your revenue. A lengthy outage could drive your customers to competitors. How do you know if your customers are generally happy with your service? If you follow site reliability engineering (SRE) principles, you can measure customer experience with service-level objectives (
皆さんはアマゾン ウェブ サービス（AWS）のSLAをご存じですか？ AWSでは200近くある各サービスごとにSLAが決められています。※2021年8月現在 「サービスごとのSLAが知りたい」 「SLAのパーセントからダウンタイムを知りたい」 「システムがダウンしたらどうしよう」 こういった疑問をお持ちの方のために、AWSの主要サービスのSLAとダウンタイムの計算方法をご紹介。最後に、万が一障害が起きた場合に備えたおすすめの対策についても解説いたします。 そもそもSLAとは？SLAとは、サービスレベルアグリーメントの略で、サービス提供者がサービス利用者に補償するサービスレベル（内容、品質水準など）を定義したものです。 サービスレベルを下回った場合の補償についても定められており、クラウドサービスの場合、利用サービスの利用料のうち数パーセントのサービスクレジットが利用できます。 SLAが定めら
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
PairsにおけるSLI/SLO再定義
SRE の基本（2021 年版）: SLI、SLA、SLO の比較 | Google Cloud 公式ブログ
Azureのインフラ構成とサービス可用性を高める仕組み (1/3)
AWS 可用性設計について考える SLAとサービス可用性設計 | DevelopersIO
https://tryhexadecimal.com/sla-uptime-calculator
SLA、SLO、SLI の比較: 相違点 | Atlassian
SLAに関する7つの誤解とは、Uptime.comが解説
稼働率（可用性）99％、99.9％などの停止時間はいくらか - 具体例で学ぶ数学
Learn how to set SLOs -- SRE tips | Google Cloud Blog
AWSのSLAとAmazon EC2上のシステム障害対策方法とは？