タグ付けされた質問 「cloud」

が主催するクラウドサービスAmazon Webサービス、アズール、グーグルや他のほとんどは公開S ervice L EVEL A greementそれらが提供する個々のサービスのために、またはSLAを。アーキテクト、プラットフォームエンジニア、および開発者は、これらを組み合わせて、アプリケーションのホスティングを提供するアーキテクチャを作成する責任があります。 これらのサービスは、単独で使用すると、通常、3〜4の範囲の可用性を提供します。 Azure Traffic Manager：99.99％または「フォーナイン」。 SQL Azure：99.99％または「フォーナイン」。 Azure App Service：99.95％または「スリーナインファイブ」。 ただし、アーキテクチャで一緒に組み合わせると、いずれかのコンポーネントが停止し、コンポーネントサービスとは異なる全体的な可用性が得られる可能性があります。 シリアル化合物の可用性 この例には、次の3つの障害モードがあります。 SQL Azureがダウンしています App Serviceがダウンしています 両方ともダウンしています したがって、この「システム」の全体的な可用性は99.95％未満でなければなりません。これを考える私の理由は、両方のサービスのSLA が次のようになっている場合です。 サービスは24時間のうち23時間利用可能です 次に： App Serviceは0100〜0200の間にある可能性があります 0500から0600の間のデータベース 両方のコンポーネント部分はSLA内にありますが、システム全体は24時間のうち2時間利用できませんでした。 シリアルおよびパラレルの可用性 このアーキテクチャには、主に次のような多数の障害モードがあります。 RegionAのSQL Serverがダウンしています RegionBのSQL Serverがダウンしています RegionAのApp Serviceがダウンしています RegionBのApp Serviceがダウンしています Traffic Managerがダウンしています 上記の組み合わせ Traffic Managerはサーキットブレーカーであるため、いずれかの地域の停止を検出し、トラフィックを作業領域にルーティングすることができますが、Traffic Managerの形式には単一障害点があるため、「システム」の全体的な可用性は99.99％を超えます。 上記の2つのシステムの複合可用性をビジネス向けに計算および文書化するにはどうすればよいですか？ 図に注釈を付けたい場合は、Lucid …

27 architecture  cloud  sla  infrastructure 

クラウドテクノロジーは現在非常に熱いですが、高価になる可能性があります。巨額の請求をせずにクラウドサービスを学習/試行するための最良の戦略は何ですか？

19 amazon-web-services  azure  cloud 

「再試行ストーム」は、クライアントが設定された回数再試行するように設定された場合に発生します。サービスの通常の動作ではパケット損失が発生するため、再試行ポリシーが必要です。 この例を見てみましょう： たとえば、サービス全体が1秒あたり80,000リクエストをサポートし、キャパシティの約80％で実行されるようにスケーリングされている場合、サービスが1秒あたり101,000リクエストを受信する原因となったトラフィックのスパイクにより、1,000リクエストが失敗します。 再試行ポリシーが有効になると、エラーが検出された場所に応じて、追加で1,000以上のリクエストが発生し、サービス全体として1秒あたり最大102,000のリクエストがプッシュされます。毎秒失敗したリクエストの数。 予測されたピークトランザクションを超えるサービスの大規模な過剰プロビジョニング以外は、非効率的です。「リトライストーム」を回避するためにどのような戦略を採用できますか？

10 serverless  cloud  distributed-systems 

パブリッククラウドにハードウェアセキュリティモジュールを配置することが可能かどうか、つまりGoogle、Amazon、Azureを使用できるかどうかを尋ねたことも、尋ねられたこともないことを認めなければなりません。 誰かが組織が完全に管理するHSMを使用できるようにするためのテクニックを見つけましたか？ クラウドとHSMの2つの概念は基本的に互いに矛盾しているように見えます。クラウドは一般に「アウトソーシング」またはオペレーティングサービスのリスクをクラウドサービスプロバイダーに転送するためです。 AzureとAWSで見られるように、フルマネージドHSMに関しては明らかに中立的な立場があります。 Azure KeyVault：Key Vaultを使用すれば、HSMとキー管理ソフトウェアのプロビジョニング、構成、パッチ適用、保守を行う必要はありません。新しいボールトとキーをプロビジョニングして（または独自のHSMからキーをインポートして）、キー、シークレット、ポリシーを一元管理します。 AWS CloudHSM：AWS CloudHSMは、クラウドベースのハードウェアセキュリティモジュール（HSM）で、AWSクラウドで独自の暗号化キーを簡単に生成して使用できます。CloudHSMを使用すると、FIPS 140-2レベル3検証済みHSMを使用して独自の暗号化キーを管理できます。 さらに、キー管理に対する非HSMベースのソリューションがいくつかあります。 クラウドキー管理（Google）：Cloud KMSはクラウドでホストされるキー管理サービスで、オンプレミスと同じ方法でクラウドサービスの暗号化を管理できます。AES256暗号化キーを生成、使用、ローテーション、破棄できます。Cloud KMSはIAMおよびCloud Audit Loggingと統合されているため、個々のキーに対する権限を管理し、それらがどのように使用されるかを監視できます。Cloud KMSを使用して、Google Cloud Platformに保存する必要がある秘密やその他の機密データを保護します。 すべてのクラウドマーケットプレイスで利用可能なさまざまなセキュリティアプライアンス。 誰かが組織が完全に管理するHSMを使用できるようにするためのテクニックを見つけましたか？

8 security  cloud  key-management 

クライアントが月に1、2回実行したいDocker化されたPythonプロセスがあります。いくつかのGoogle APIを呼び出し、その結果をGoogleスプレッドシートに保存します。ネットワーク要求は受け付けません。Dockerコンテナーを起動してすべてをシャットダウンする「マジックボタン」を1つ提供したいと思います。 背景：これは以前、これをDocker Cloud経由でAWS EC2マイクロインスタンスにデプロイしていました。私のクライアントはDocker Cloudアカウントを取得し、コンテナーをオンデマンドで比較的簡単に実行できました。このワークフローには2つの問題があります。 プロビジョニングされたEC2インスタンス（Dockerホスト）は、Dockerコンテナーが実行されたかどうかに関係なく、24時間365日稼働していました。これは高価になりました。 Dockerクラウドは1か月前にシャットダウンしました。 代替手段は、GoogleおよびAWS Kubernetesサービスのようです。私の予約は、クライアントが使用するには複雑すぎるためです。助言？

7 docker  cloud