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

が主催するクラウドサービス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 

私は、各タイプのサーバーのセキュリティ/管理の容易さ/法医学能力の比較のようなマトリックスに興味があります。また、各タイプのいくつかの主要な機能を忘れる場合があります。 私は型について一般的な考えを持っていますが、場合によっては（たとえばアプリケーションの自動化が複雑になった場合）型を選択するときに参照行列が役立ちます。 それが広すぎるという懸念を避けるために、それを複数の質問に分割すると情報が散らばり、セキュリティ比較に関する質問も各タイプを比較する必要があると感じています。

15 servers  architecture 

beats入力プラグインに関するいくつかの調査、特にこれを書き換えた後、複数のエントリタイプを処理するために、1つのビート入力のみを使用する必要があるのか​​、それとも複数を使用する必要があるのか​​疑問に思います。 およそ500台のマシンからのイベントがあり、20/80のWindows / Linuxディストリビューションがあります。マルチプルビートシッパー、ファイルビート、メトリックビート、そしておそらくパケットビートを使用する予定です。 タイプ/ OSカップルごとに1つの入力を使用することに関心がありますか、それとも1つの入力だけで、フィルターパイプラインで「if type = ...」で十分ですか？

10 architecture  performance  logstash 

で、私のチームは、我々は持つ1台のジェンキンスサーバ持つ1つのマスターノードと1つのスレーブノードと同じサーバ内に。Jenkins Pipelinesを使用し、すべてをで囲みますnode{}。 で同僚のチーム私はいくつかの理由のために、彼らが持っている、それを見てきた一つのマスターノードと無スレーブノードを。すべてのビルドはマスターノードで実行されます。 質問： これは悪い習慣ですか？ マスターノードが1つしかない場合、悪い影響はありますか？ 私の設定（1つのマスターと1つのスレーブ）は悪い習慣ですか？

9 jenkins  architecture 

ビジネス/企業の要件と私たちの建築家の好みの組み合わせにより、私には少し離れているように見える特定のアーキテクチャにたどり着きましたが、私は非常に限られた建築知識しかなく、クラウド知識がさらに少ないため、確認するための健全性チェックが大好きですここで行うことができる改善がある場合： 背景：ゼロから完全に書き直した既存のシステムの代替品を開発しています。これには、BAPI / SOAP Webサービスを介してSAPインスタンスからデータを調達し、SAPにないデータ用に独自のデータベースを使用する必要があります。現在、管理対象のすべてのデータは、分散アプリケーションのローカルDB、または移行元のMySQLデータベースに存在します。既存の分散アプリの機能を複製する一握りのWebアプリケーションを作成し、管理するデータに対して管理関連の機能を提供する必要があります。 ビジネス/エンタープライズ要件： 私たちが管理するデータベースは、MS SQL Serverに実装する必要があります 作成するデータベースの数を最小限に抑える フェーズ1では、アプリケーションをAzureにデプロイしますが、将来的にはこれらのアプリケーションをオンプレミスにする機能が必要です 運用チームは、コードの管理が大幅に簡単になると感じているため、すべてをドッキングすることを望んでいます。 データの複製を最小化/排除 コーディングスタックは、マイクロサービスと管理アプリの場合は.NET Coreになりますが、メインのフロントエンドアプリケーションの場合はAngular 5になります。 これらの要件から、私たちの建築家はこの設計を思いつきました： 私たちのフロントエンドは、一連のマイクロサービス（「ドメイン」レベルでかなり大きいため、この用語を軽く使用します）からフィードし、各ドメインで読み取りサービスと書き込みサービスに分割されます。どちらもスケーラブルで、Kubernetesを通じて負荷分散されます。それぞれには、データベース内の読み取り専用のコピーがコンテナ内にアタッチされており、読み取り専用コピーへの更新をプッシュする書き込みに使用できるdbの単一のマスターインスタンスがあります。 （低品質の画像については申し訳ありませんが、当然、建築家の頭を除いて、これに関する実際のドキュメントがないため、メモリからやり直しています。） サービス間の通信は、各サービスがリッスンし、関連するメッセージを処理するメッセージキューを介して行われます。情報のために通信を提供するためのサービスを必要とするものはまだ特定されていないため、これの主な用途は電子メールの生成です。複数のサービスの関与を必要とする「ビジネスロジック」に関連するものは、フロントエンドから流れる可能性が高く、フロントエンドは各サービスを個別に呼び出し、原子性を扱います。 私の見解では、間違った方法でこすりつけているのは、読み取り専用のdbインスタンスがサービスのDockerコンテナー内でスピンアップしていることです。サービス自体とdbは、負荷の点で要求が大幅に異なるため、それらを個別に負荷分散できれば、はるかに理にかなっています。MYSQLには、マスター/スレーブ構成でそれを行う方法があると思います。この場合、負荷が高くなるたびに新しいスレーブを起動できます。特に、システムがクラウドにあり、インスタンスごとに支払いを行っている場合、別のdbインスタンスのみが必要なときにサービス全体の新しいインスタンスをスピンアップすると無駄になります（反対に、実際にちょうど新しいデータベースコピーをスピンアップすると、 Webサービスインスタンスが必要です）。ただし、これに対するMS SQL Serverの制限はわかりません。 私の最大の懸念は、MS SQL Serverの実装に関するものです。読み取り専用インスタンスをサービスに非常に密に結合すると、気分が悪くなります。これを行うより良い方法はありますか？ 注：私はソフトウェアエンジニアリングについてこれを尋ねると、ここで私を指摘しました。これが適切なSEではない場合は、申し訳ありません。 また、MS SQL Serverタグはありません

7 azure  architecture