2018年のマイクロサービス開発の5つのトレンド

2017年はDevOpsにとって重要な年でした。エコシステム内のプレーヤーの数が大幅に増加し、CNCFを使用したプロジェクトの数が3倍になりました。 1年先を見据えて、イノベーションと市場の変化がさらに加速すると予想しています。 以下では、2018年のマイクロサービスの分野の動向を調べました。サービスバンドル（いわゆる「メッシュ」）、イベント駆動型アーキテクチャ、ネイティブコンテナセキュリティ、GraphQL、およびChaosエンジニアリングです。

1.サービスバンドルが人気です！

サービスバンドルまたは「メッシュ」、サービス間の通信を改善するための専用インフラストラクチャレイヤーは、現在クラウドコンテキストで最も議論されています。 コンテナがより一般的になるにつれて、サービストポロジはより動的になり、ネットワーク機能の改善が必要になります。 サービスバンドルは、サービスの検出、ルーティング、負荷分散、ヘルスチェック、および可観測性を通じてトラフィックを管理するのに役立ちます。 サービスバンドルは、コンテナの揺るぎない複雑さを抑えようとします。



明らかに、HAProxy、traefik、NGINXなどのロードバランサーがデータプレーンとして再構築され、表示されるようになったため、サービスグリッドはますます普及しています。 大規模な展開はまだ見ていませんが、実稼働環境のライブサーバーで既にバンドルを使用している企業については知っています。 さらに、サービスバンドルはマイクロサービスまたはKubernetes環境専用ではなく、サーバーのないVM環境でも使用できます。 たとえば、国立生物工学情報センター（NCBI）にはコンテナはありませんが、リンカードが使用されています。



サービスリンクは、カオスエンジニアリングにも使用できます。これは、「乱流状態に耐えるシステムの能力に対する信頼性を高めるように設計された分散システムでの実験の規律」です。 サービスバンドルは、各ノードで実行されるデーモンをインストールする代わりに、環境に遅延と混乱のオブジェクトを導入できます。



IstioとBuoyant's Linkerdは、カオスエンジニアリングにおける最大の取引です。 Buoyantは、昨年12月にKubernetesのオープンソースサービスバンドルであるConduit v0.1をリリースしたことに注意してください。

2.クライミングイベント駆動型アーキテクチャ

ビジネスの俊敏性の必要性が高まるにつれて、1つのサービスがイベントをディスパッチし、このイベントに続く1つ以上のオブザーバーコンテナが応答して、知識なしで非同期にロジックをトリガーするプッシュまたはイベントベースのアーキテクチャへの動きが見られ始めましたイベントのプロデューサーによる応答の事実。 要求駆動型アーキテクチャとは異なり、イベント駆動型システムでは、開始コンテナでの機能プロセスとトランザクションのロードは、子コンテナでのリモートプロセスの可用性と終了とは無関係です。 これの追加の利点は、開発者がそれぞれのサービスをより独立して開発できることです。



開発者はイベントを生成するためのコンテナ化された環境を作成できますが、サービスとしての機能（FaaS）は基本的にこの品質を実現します。 FaaSアーキテクチャでは、関数はテキストとしてデータベースに保存され、イベントによってトリガーされます。 関数を呼び出した後、APIコントローラーはメッセージを受信し、ロードバランサーを介してメッセージバスに送信します。メッセージバスはメッセージを計画し、コンテナー呼び出しに提供するためにキューに入れます。 実行後、結果はデー​​タベースに保存され、結果がユーザーに送信され、関数は再度呼び出されるまで廃止されます。



FaaSの利点は次のとおりです。1）コードを記述してからサービスを開始するまでの時間を短縮します。作成またはソースコードを超えるアーティファクトがないためです。 ただし、FaaSは完全に問題がないわけではありません。 FaaSではサービスのすべての部分を分離する必要があるため、検出、管理、整理、および制御が困難な多くの機能が存在する可能性があります。 最後に、依存関係を含む完全な可視性がないと、FaaSシステムのデバッグが難しく、無限ループが発生する可能性があります。



FaaSは現在、長い呼び出し、メモリにロードされる大量のデータ、および一定のパフォーマンスを必要とするプロセスにはあまり適していません。 開発者はバックグラウンドジョブや一時的なイベントにFaaSを使用しますが、ストレージレイヤーが改善され、プラットフォームがより効率的になるにつれて、ユースケースは時間とともに拡大すると考えています。



2017年の秋に、Cloud Native Computing Foundation（CNCF）は550人以上にインタビューしました。31％がサーバーレステクノロジーを使用し、28％が今後18か月間使用する予定です。 調査は、どの特定のサーバープラットフォームが使用されているかという質問によって深まりました。 サーバーレステクノロジーを使用している169人のうち、77％がAWS Lambdaを使用していると答えました。 Lambdaはサーバーレスプラットフォームをリードするかもしれませんが、周辺には興味深い機会があるかもしれません。 これらの境界の計算は、IoTおよびAR / VRにとって特に重要です。

3.セキュリティニーズは変化しています

コンテナにパッケージ化されたアプリケーションは、カーネルにアクセスするため、デフォルトではほとんどの場合安全です。 VM環境では、唯一の視点は仮想デバイスドライバーです。 コンテナ環境に移行すると、OSにはシステムコールとセマンティックな意味があります。 はるかに激しいコミュニケーションのようです。 以前は、オペレータはエージェントを仮想マシンに転送することでこれらの機能の一部を取得できましたが、それは困難でした。 コンテナはより優れた可視性を提供し、コンテナ環境での統合はVM環境と比べて簡単です。



上記を念頭に置いて、「451 Research Survey」では、コンテナを受け入れるための安全性が最大の障害であるという報告を見つけることができます。 脆弱性は元々、コンテナ環境における主要なセキュリティ問題でした。 公共レジストリですぐに使用できるコンテナイメージの数が増えているため、それらに脆弱性がないことを確認することが重要になりました。 時間が経つにつれて、画像のスキャンと認証は必需品になりました。



ハイパーバイザーがアクセスおよび制御ポイントとして機能する仮想化環境とは異なり、カーネルルートアクセスを持つコンテナーは、最終的にカーネル上のすべてのコンテナーにアクセスできます。 次に、組織はコンテナがホストと対話し、どのコンテナが特定のアクションまたはシステムコールを実行できるかを確認する必要があります。 グループと名前空間の適切な構成を確保するためにホストを強化することもセキュリティにとって重要です。



最後に、従来のファイアウォールは、ネットワークフローを許可するためにIPアドレスルールに依存しています。 動的オーケストレーターはIPアドレスを再利用するため、この方法はコンテナー環境には適用されません。 リアルタイムの検出と応答は、実稼働環境に不可欠であり、コンテナー環境にインプリント（指紋）し、動作のベースラインの詳細な図を構築することで実現されるため、異常な動作を簡単に検出して攻撃者を扇動します。 451レポートは、調査した企業の52％が生産でコンテナを使用していることを指摘しています。

4. RESTからGraphQLへの移行

2012年にFacebookによって作成され、2015年にオープンソースとして公開されたGraphQLは、言語とクエリの実行であるAPI仕様です。 GraphQLタイプシステムにより、開発者はデータスキーマを定義できます。 既存のリクエストやクライアントアプリケーションの再構築を損なうことなく、新しいフィールドを追加したり、フィールドをクリア（非推奨）したりできます。 GraphQLは、特定のデータベースやストレージエンジンに関連付けられていないという点で強力です。



GraphQLサーバーは、サービス機能の全範囲を表す単一のHTTPエンドポイントとして機能します。 （RESTのようなエンドポイントではなく）タイプとフィールドの観点からリソース間の関係を定義することにより、GraphQLはプロパティ間のリンクをたどることができるため、サービスは単一のクエリを使用して複数のリソースからデータを受信できます。 さらに、REST APIでは、1つの要求に対して複数のURLをロードする必要があり、ネットワークの負荷が増大し、要求が遅くなります。 ヒット数が減少すると、GraphQLは各データクエリに必要なリソースの量を削減します。 返されるデータは通常、JSONでフォーマットされます。



RESTよりもGraphQLを使用することには、追加の利点があります。 まず、クライアントとサーバーは「アンティ」であるため、別々に維持できます。 RESTとは異なり、GraphQLはクライアントとサーバー間の通信に同様の言語を使用するため、デバッグが容易になります。 クエリフォームは、サーバーから取得したデータのフォームと完全に一貫しているため、GraphQLは、SQLやGremlinなどの他の言語に比べて非常に効率的かつ効果的です。 要求には応答の形式が反映されるため、偏差を検出でき、正しく解決されないフィールドを定義できます。 クエリはよりシンプルであるため、プロセス全体でより安定しています。 この仕様は、外部APIをサポートするために最も一般的ですが、内部APIにも使用されていることがわかります。



GraphQLユーザーには、Amplitude、Credit Karma、KLM、NY Times、Twitch、Yelpなども含まれます。11月、AmazonはGraphQLサポートを含むAWS AppSyncを起動して、GraphQLの人気を確認しました。 GraphQLがgRPCおよび代替TwitchのTwirp RPCフレームワークのコンテキストでどのように進化するかを見るのは興味深いでしょう。

5.カオスはより有名になっています。

Netflixで最初に普及し、後にAmazon、Google、Microsoft、Facebookで普及した彼らは、生産の問題に​​耐える能力の信頼性を高めるシステムを作成するためにChaosを実験しました。 過去10年にわたって、カオスエンジニアリングは正当なテクノロジーに進化してきました。 Chaos Monkeysで始まり、実稼働環境でサービスをオフにして、障害注入テスト（FIT）の範囲を拡大し、大規模環境に適したChaos Kongを導入しました。



表面的には、カオスエンジニアリングは単なる注入のtle騒に過ぎないようです。 システムハッキングは楽しいこともありますが、必ずしも生産的であるとは限らず、有用な情報を提供できるとは限りません。 カオス技術は、インジェクションの失敗だけでなく、トラフィックの急上昇、リクエストの異常な組み合わせなど、既存の問題を特定するための幅広い範囲を具体化します。 特定の前提条件を確認することに加えて、彼は新しいシステムプロパティを識別する必要もあります。 システムの弱点を特定することにより、チームは回復力を向上させ、ネガティブなユーザーエクスペリエンスを防ぐことができます。



ニューラルネットワークやディープラーニングなどの新しいテクノロジーは非常に複雑であるため、何かがどのように機能するかを決定することは、それが機能することを証明するよりも重要ではなくなる場合があります。 カオステクニックは、システムの整合性をチェックして不安定性を検出することにより、この問題の解決に役立ちます。 エンジニアは、ますます複雑化するシステムの信頼性を高めるために努力するため、これはさらに受け入れられるプラクティスになる可能性があります。



カオスエンジニアリングがより一般的になると、既存のオープンソースプロジェクト、商用オファー、または前述のようにサービスバンドルを通じて実装されるという形をとることができます。