ディレクトリ
プロジェクトでは、これが進化の過程であることを覚えておいてください10--
回避または以下のアプリケーションから削除されなければならない理由をこの記事では、我々は探検：状態サービスは、緊密に結合された、水平方向の拡張が有効になっている、アプリケーションのうち、各セクションの設定は、自動的にデプロイ監視、制御するパイプラインを構築し、環境を構成するには「ユニークさ」。
だから、私は、アプリケーションを改善する方法についての記事のいくつかの使いやすさと柔軟性を完了しており、過去数ヶ月で私は結論になってきました。多くの人々にとって、これは非常に重要なテーマです。私はそれが可用性設計のためにこのルートを行く、そしてどのように解決するために何を意味するのか、以前の記事で説明してきました。
しかし、別の問題は、私はアプリケーションでより大きな可用性と柔軟性を実現するために、物事の種類を行うべきであるということです来ますか？回復力を改善するために、レガシーアプリケーションをアップグレードする方法？開発者として、どのように私はこれを覚えておくために何ができますか？
だから、私はあなたがアプリケーションの内容の要約リストを見つけるべきだと思う、これらの変更は、あなたの可用性向上します/ 弾力性を、および/ またはこの2つの要因の適用を高めながら、あなたが望むなら、あなたはこれらの事を避ける必要があります。
だから私は両方の方法を向上させることができることを見出したためのスタートは、私が使用し続けて二つの用語でみましょう、と私たちは同じことを話しているときにのみ発生します。
- アベイラビリティ（可用性） -アプリケーションの能力を実行し続けることができた場合でも大幅なダウンタイムの重要な機能。だから、それは最小限のユーザにサービスを提供し続ける能力に影響を与えることができます。
- 弾性（復元力は ） -でも主要な障害や過渡電流処理能力のイベントで、アプリケーションが作業を続けることができたときです。したがって、進行中の現在の作業の完了。
したがって、更なる研究が、質問は私が回避または前方の私の立場を改善するために、アプリケーションから削除の種類べきものなり。
アイテム＃1 -状態サービスで
全体的に、これは、可用性と耐障害性の問題を解消するために重要な要素であり、かつ物議を醸す問題かもしれませんが、ここでは、私はこれについてお話したいと思います。サービスは、（メモリまたは他の状態で）特定のステータスを持っている場合、それは他の場所へのフェールオーバーがより難しく、私には意味します。私は、メモリ内で行われている場合、それは非常に困難になる状態をコピーすることは知っていました。そのような場合はSQL やRedisのこのような独立した店、それが容易になるが、同時に、可用性のこの形がより困難になり、追加の複雑さを、必要とします。あなたはしている場合はSLA に追加「9」と、特に。状態に依存アプリケーション構成要素は、それが最善であればこのように、一般的には、それが回避されます。
また、状態サービスも需要があるとして成長・拡大する能力に制限を含むクラウドで他の問題を引き起こす可能性があります。完璧な例は、「スティッキーセッション」、サーバーへのルートと、私たちは同じサーバにあなたを送信し続けることを意味します。これは、スケールの反対は、すべてのコストで避けるべきです。
あなたがレガシーアプリケーションを扱っている、と削除のステータスが不可能な場合は、少なくともメモリに加えて、状態管理に確認してください。あなたが会話を削除することができない場合たとえば、それを移動しSQL およびコピー。
アイテム＃2 -作業が密接に結合させます
私は上に概説した2つの重要な要素にこれがポイント。タイトは、アプリケーション・コンポーネント間の結合するとき、あなたはいくつかの良いを作成します。最終的に失敗し、何かを拡張することはできません。それは良いの解決策になることができます拡張を構築する能力を防ぐことができます。
あなたのアプリケーションのプログラムがあると、私たちは一般的な例を見てみましょうAPIの層とAPI あなたとのUI を内蔵したフロントエンドのWeb プロジェクトを。次に、APIのデータベースと直接対話。
これは非常に一般的な従来のモデルです。この問題は、負荷によって引き起こされたWeb アプリケーションとバックエンドの需要API 密結合、およびそのため、障害が別の失敗を意味します。
さて、あなたがすることをしてみましょうさらに言うAPI 、外の世界にさらされるが（アプリケーションが拡張することができるように、安全な慣行に従ってください。サウンド良い、右。
深い理解に加えて、互いに直接通信するすべてのアプリケーションの要素によって、あなたは今でカスケード故障プログラムを作成することができ、完全にあなたのアプリケーションを破壊します。
たとえば、あなたの顧客はあなたの使用することを非常に困難を決定するAPIを、各30 それらの多くは、完全なダンプ秒を抽出するために、あなたのデータを使用することを決定した、またはあなたがのためにサインアップするAPIの顧客。それは次のような効果につながります。
- APIの需要の増加につながったウェブメモリとレベルでCPUの消費量が増加します。
- これは、アプリケーションのパフォーマンスの問題は、ページをロードする原因となります。
- これがためで、その結果、断続的な地域を引き起こす可能性がありますAPI の高いトランザクション要件SQLの要件。以下のためにSQL の需要が増加すると、アプリケーションがリソースのデッドロックが発生した原因となります。
- アプリケーションに障害が発生した場合、これらのリソースは、他の問題、デッドロックのユーザーエクスペリエンスにつながることができます。
今、あなたは、はい、ケビンを考えることができるが、私はクラウドで自動スケーリングを有効にすることができ、それはすべてのこれらの問題を解決することができます。私の答えは、同時に、あなたの法案は、制御不能なインフレを登場されます。だから、明らかに、あなたのCFO コストと暴走インフレのは、悪い習慣を相殺するために許容可能です。
我々はこの問題を解決することができる状況があることであるAPIの我々は問題を解決するための拡張ではなく気まぐれに、別々に計算管理できるようにすることを、別個のコンピューティング層に分割。それから私は、個々のオプションの私の許可申請の拡張子を持っています。
また、私はあなたが次のアプリケーションの合理的な応答時間を超えた場合に拡張キューの深さを拡張することができます達成するために、負荷分散の練習、としてキューに入れることができます。私からも制限することができAPIのアプリケーションからの要求や優先順位付けのメッセージ。それから私は、より高い柔軟性を提供するために、メッセージキューをコピーすることができます。
アイテム＃3 -スケールを有効にします
今、私が知っている、私は規模が非常に悪いと思いますが、重要な部分をされ、「制御します」。私はステートレスになるためにサービスを行うことにより、平均値、および実装をデカップリングの練習は、ビューの柔軟性と使いやすさの点から、プログラムのコピーを、実行することができます1つまたは複数のサービスを作成することができ、これは、さまざまな利点をもたらすことができます。それは牛にあなたのペットからサービスする、あなたは、もはや他がそれを交換したために、1ダウンするかどうかを気にしません。それは少し思考の良い方法であるハイドラ、のようなものです。
項目＃4 -アプリケーションの各部分のうち設定されます。
近いあなたの設定やアプリケーションコードは大きな変更の難しさ、接続されています。あなたのコードが密結合された場合、および必要性が構成変更を行うために展開されるように、この手段を使用すると、エンドポイントを変更する必要があること、それがますます困難になるだろう。したがって、あなたができる最善のことは、アプリケーションから削除されます構成設定を開始しています。かかわらず、あなたはどのように見えるかの、これは重要なことです。次の理由の場合：
- セキュリティ
- 保守性
- 自動化
- 変更管理
項目5 -自動配信のパイプラインを作成します。
多くの場合、自動化は、あなたがより高い得る場合は特に、高可用性への鍵である9S 時間レベルを。単純な事実は、秒数です。
また、自動展開も構成のずれを管理するのに役立ちます、単純な事実は、その構成のずれあなたは何も領域を確保するために管理しなければならないので、セカンダリゾーンを維持することがより困難です。展開パイプラインを自動化することで、この状況を解消するために、すべてを強制的に。各変更は、スクリプトや自動化されなければならない場合には、環境構成のずれで起きて見ることはほとんど不可能です。
アイテム＃6 -モニタリング、監視、モニタリング
高可用性と柔軟性のもう一つの要素は、監視されています。あなたは数年前に私に尋ねた場合は、ほとんどの開発者は、問題が最初であると思うし、それは「私が？これを確実にするにはどうすればよい」これが問題ではあるが、それでも多くの開発者のビューにいくつかの方法付け足しのように、しかし、大きな疑問がある「どのように私は監視し、それが動作するかどうかを知っていますか？」マイクロサーバーコンピューティングサービスのビューの上昇なしに、我々は我々が展開することを、コードの各部分を監視することができるようにする必要性を行います。したがって、我々はあなたがこの質問に答えるために、すべての新製品を構築することを理解する必要があります。
これは、内に記録カスタムテレメトリような単純なようなものであってもよいアプリケーションの洞察で、またはレコードの着信と発信要求、記録異常。あなたはこれらの目標を達成していない場合は、我々は、特定のプログラムが実行されていることを確認することはできません。
アイテム＃7 -制御の設定
これは私が上記のコメントに基づいて作られたものです。私はこのタイプの実装に遭遇した人々を参照してください最大の過ちは、彼らは、環境の設定を変更する方法を管理していないということです。結局、これはに導いた「ペット」VS「牛」の考え方。：私のキャリアは読みバナー上記の彼のオフィス、上司を持っていた「サーバーは牛、ないペットですが...... 。時にはあなたがハンバーガーをしなければなりません。」
そして、面白いように上記の文は、それが真実の要素を持っていることです。あなたが設定を変更することが許可され、リビジョンが環境に直接適用した場合、自動で任意の信頼に依存しないためにつながります。また、モニタリングを可能にし、実際の高可用性または弾力アーキテクチャの他のすべての要素は完全に無関係。
したがって、あなたができる最善のことは、自動化されたパイプラインを使用することで、必要に応じて、任意の変更を行い、人々がアクセスできないように、それは、メトリックとログを読みに加えて、理想的には、パイプを通して最善をプッシュする必要があります生産環境。
アイテム＃8 -をなくし環境「独自性」
上記のように、我々はすべてのコンテンツ環境が再現可能であることを確認する必要があります。理論的には、私は環境を破壊することができるはず、ボタンをクリックすると、新しい環境を展開することができます。これは、すべてのスクリプトを記述することによって行うことができます。私はテラフォーム大ファンを、あなたはこの問題を解決することができます、しかし、bashのスクリプト、PowerShellの、CLI 、助け自分自身。
より多くのあなたがコンテンツを削除することができ、簡単にそれをコピーして、少なくとも1つの活性作成することです/ パッシブ環境を。
アイテム＃9 -可用性のためのスタートモード
あなたが行くようにアプリケーションの柔軟性を高めるために、より実用的な達成するために道に沿っている場合は、次の方法を検討する必要があります建設されるフレキシブルタイプの作成を支援する新しいサービスを構築するとき。これらのモードは、次のとおりです。
- エンドポイントのヘルスモニタリング - あなたが助けに外部ツールを使用することができます作るためにあなたのアプリケーションに機能チェックを達成します。
- キューベースのロードバランシング - 使用は、アプリケーション間の抽象化層を配置着信要求を処理する方法バッファキューのような、またはより柔軟な方法で作用します。
- スロットル - このモードでは、消費電力を制御しながら、あなたは、システムの要件を満たすことができるように、リソース消費量を管理することができます。
- ブレーカは - 私の経験では、このモデルは非常に貴重です。あなたのサービスは、増分再試行を使用して、影響を受けた下流のサービスに戻るにはスマート十分なはずです。
- バルクヘッド - このモードは、理由はアプリケーションによって引き起こされるサービスのシャットダウンの耐障害性を確保するために分離し、注意を利用閉じていません。
- 取引を補償 - 非常に重要なあなたは、トランザクションが元の状態に戻って圧延され、パーティションや耐障害性のいずれかのタイプを使用して、または別の懸念を持っている場合。
- リトライ - 達成するための最も基本的なモデルは、それは一過性、耐障害性の確立のために不可欠です。
項目10 -これが進化する過程であることを覚えています
本明細書で先に述べたように、ここでの意図は、あなたがより多くのクラウドベースの機能を構築するため、アプリケーションの柔軟性を向上させたい場合は、私が提供できる最高のアドバイスは、これは機会のための反復的なプロセスと見ていることを覚えておくことがあり、ありますあなたのアプリケーションを更新し、柔軟性を向上させます。
例えば、私は通知を送信するために持っているとAPIの変更を。あなたはこれらの更新をしたい場合は、多分私は、キュー、ログを達成し、柔軟性を向上させるためにマイクロにサービスを拡張するためにいくつかの変更を行うことができます。これを行うと、あなたは、アプリケーションの位置を向上させることになるでしょう。
