デベロップメントオンラインゲーム開発に最適なプログラミング言語は何か?最近のゲーム開発者は、ゲームをより分かりやすく、魅力的なものにすることに注力しています。そのためには、最適なプログラミング言語を選択するという問題が生じます。すべての要件を満足する言語を選ぶのは簡単ではありませんが、JavaScriptのようなリーダに頼ることは可能です。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Transfer)は、マイクロサービス間の通信におけるデファクトスタンダードになっています。実際、それは非常に残念なことです。こんなことになったのでしょう?そう、RESTが登場した頃には、もっと悪い選択肢しかなかったのです。Fielding氏が2000年にRESTを提案したとき、RESTはとても不味いサンドイッチの中にあった、ケールのサンドイッチだったのです。関連スポンサーコンテンツ当時使われていたのは、SOAPやRMI、CORBA、EJBでした。その中でJSONは、XMLの授けたもうた安息でした。URLを使ってテキストを書き出すのは簡単だったからです。加えて、JavaScriptがブラウザで本格的に使用されるようになっていたため、それまでのSOAPよりも、RESTを扱う方がはるかに簡単だったのです。昨今のマイクロサービスのトレンドとは違い、当時のアプリケーションは従来型のモノリシックな3層アプリケーションでした。それらが通信対象とする外部トラフィックのソースは大半がブラウザだったので、何かを生成する必要がある場合には、RESTは便利な選択だったのです。多くの人たちは、WebSphereのような大規模な商用製品から、JettyやTomcatへの移行を始めていました。これらはEJBを扱う機能さえ持っていなかったので、RESTは都合がよかったのです。これがマイクロサービスとどう関わっているのでしょうか?初期のマイクロサービスのパイオニアたちは、今日の人たちとは違う理由からマイクロサービスに移行しました。彼らは大きな規模に対処しなければならなかったのです。非常に多くのユーザを獲得するようになったことで、単一のモノリスではすべてを処置できなくなりました。今日の多くの企業とは違い、大きな動機はコストではなく時間でした。サービスの提供が常にニーズから遅れていたのです。ユーザ数はますます増えて、モノリスでは処理できなくなったため、アプリを小さな部分に分割して、それらを何千という数のサーバに、さらに最終的には仮想マシンにデプロイできるようにしました。それと同時に、アプリケーションを非常に早くデプロイできるようになりました。このモデルを採用した企業が、生き残ることができたのです。このレースの間は、自分たちの行なったことを考える時間はあまりありませんでした。彼ら初期のパイオニアたちは、指数関数的に増加するユーザと競争に対処しなければならなかったので、戦略的な解決策を選ぶことは理に叶っています。そのひとつが、サービス間の通信手段としてのRESTだったのです。RESTはマイクロサービスに向いていないかアプリケーションをプログラムする場合、プログラム言語は最終的にマシンコードになります。JavaやJavaScriptのような“インタープリタ”言語であっても同じことです。マシンコードに直接コンパイルされなくても、JITないしジャスト・イン・タイムコンパイラが使用されます。VMはまさに、現在コンピュータ科学の奇跡なのです。この奇跡を無駄にするのでしょう?マシン用に最適化されたバイナリメッセージを、サービスに最適化されたプロトコルで送信するのではなく、私たちは人間に最適化されたメッセージを使用しています。JSONやXMLといったものを、本を送信するために設計されたプロトコルを使って送信しているのです。これがどれほどばかげたことか、考えてみてください!バイナリのプログラムがあって、それがバイナリ構造をテキストに変換して、ネットワーク上をテキスト形式で送信して、受け取ったマシンが解釈し、バイナリ構造に戻して、アプリケーションで処理しているのです。最近のCPUでは、キャッシュミスを回避することが重要です。残念なことに、大量のJSONや文字列の解析は、このキャッシュミスを発生させるのです!RESTを使用する理由としてよく引き合いに出されるのが、“可読性”があるためデバッグが容易である、という点です。読みにくいのはツーリングの問題です。JSONテキストに可読性があるのは、それを読むことのできるツールがある場合に限られます。それがなければバイトの羅列に過ぎません。データが送信される時間の半分は、圧縮ないし暗号化されています。どちらも可読性はありません。そもそも、人がこれを読んで、どの程度“デバッグ”できるのでしょうか?1キロバイトのJSONを毎秒わずか10個、要求するサービスがあるとします。これは1日で860メガバイト、“戦争と平和”の250倍に相当します。これほどの量は誰にも読めません。単なるお金の無駄です。一方で、バイナリデータを送信する必要がある場合や、JSONではなくバイナリフォーマットを使用したい場合もあります。この時は、データをBase64エンコードしなければなりません。これはつまり、データを2度シリアライズしていることに他なりません。これもまた、現代のハードウェアを使用する効率的な方法ではないのです。最終的にRESTは、HTTP上のハックとして実装されました。HTTPは現在、サービス間でトランスポートデータを送信するハックとして使用されています。HTTPは元々、インターネット内で本を持ち歩くために設計されたものです。サービスが相互通信するために使用するものではありません。なく、すべてのデータを処理するアプリケーションに最適化されたフォーマットを使用するべきです。よいマイクロサービス通信とは何か?RESTがサービス間通信のベストチョイスではないとするならば、何がベストなのでしょうか?マイクロサービス通信用に設計されたプロトコルに私たちは何を望むのか、いくつか考えてみましょう。最初に、双方向であることが必要です。クライアントがサーバを呼び出すことしかできなければ、RESTでは大きな問題になります。双方が互いに同じ能力を持つことによって、自然な方法でアプリケーション間のインタラクションを生成できるのです。なければ、サーバ呼び出しをシミュレートするための長期ポーリングなど、不格好な回避策を考えなくてはなりません。HTTP/2であれば部分的に回避可能ですが、やはりクライアント側から起動する必要があります。必要なのは、クライアントとサーバが相互に、自由にコールできることなのです。ひとつの要件は、サービス間の接続は同じコネクションで、同時に複数のリクエストをサポートしなければならない、ということです。これは多重化(multiplexing)と呼ばれるものです。この場合、ひとつの接続でリクエストを個々に区別するための、何らかの方法が必要になります。これは、ひとつのリクエストが終わってから次の要求が始まるHTTPとは違います。多重化では、さまざまなリクエストをトラッキングしなければなりません。これを行うよい方法のひとつは、それぞれのリクエストをバイナリフレームで表現することです。各フレームにはリクエストと合わせて、関連するメタデータを保持することができます。それを使用して、フレームを適切な場所に配信することが可能になるのです。単一コネクション上でデータを送信する場合には、リクエストを断片化する機能が必要です。ひとつのコネクション上の大きなリクエストは、他のすべてのリクエストをブロックします。いわゆる非割り込み型(head-of-the-line)ブロッキングです。それを回避するためには、リクエストを小さなサイズに断片化して、ネットワーク上を送信することが必要になります。送信されるデータはフレーム化されているので、より小さなフレームのフラグメントに分割されて、反対側で再組み立てされる可能性があります。この方法で、リクエストを互いにインターリーブすることができるのです。大きなリクエストが小さなリクエストをブロックすることがなくなり、より応答性のよいシステムを構築できます。接続に関するメタデータを交換する機能も有効です。場合によっては、全体的なトレースレベルの設定や、辞書ベースの圧縮に関する情報交換など、ビジネストランザクションの一部ではない送信データがあります。これらはビジネスロジックとは無関係ですが、接続レベルでコントロールされるものです。メタデータを交換することで、これが実現できます。アプリケーションのコードには、リストを取得したり、リストを返したり、あるいはその両方を行う関数やメソッドが少なくありません。マイクロサービスでも、これはよくある話です。RESTはこのような状況にうまく対処できません。その結果、あらゆる種類のハックや複雑な処理が発生します。必要なのは、アプリケーションで行っているように、反復的なデータを簡単かつ自然な方法で処理できるプロトコルです。データのリスト全体を読み込んで処理し、すべてを処理した後にデータのリストを返す、という方法は合理的ではありません。到着したデータを順次処理できることが望まれます。データをストリーミングできるようにしたいのです。長いデータリストのある場合は、データが処理されるまで待ちたくはありません。データが使用可能になったときに送信して、その都度、応答を返してもらうのが望ましい方法です。これによって、さらに応答性のよいシステムが実現します。この方法は、ファイルからバイトデータを読み込んでネットワーク越しにストリーミングするような場合から、データベースクエリの結果の返送、ブラウザのクリックストリームデータのバックエンドへの送信まで、あらゆる場面で利用できます。プロトコルにファーストクラスのストリーミングサポートがあれば、Sparkなどの別システムを用意してストリーム処理を行なう必要はなくなります。データを保存する要求がなければ、Kafkaのようなものも必要ありません。ストリーム経由で送信されるデータに対して、次に必要なのはアプリケーションフロー制御です。バイトレベルのフロー制御は、すべてが同じサイズで、一般的にネットワークカードの観点から処理に要するコストが同じである、TCPのようなものならばうまく機能します。アプリケーションでは、すべてが同じコストではありません。10ミリ秒で処理可能な10キロバイトのメッセージもあれば、処理に10秒を要する10バイトのデータもあります。マイクロサービスに見られるもうひとつのシナリオは、処理可能なデータ速度よりも、ダウンロードプロセスの処理レートが遅いことです。この場合、TCPバッファがフルになることはありません。ダウンストリームサービスの応答性を維持するために、負荷をかけ過ぎないようにトラフィックのフローを制御する、何らかの方法が必要になります。基盤となるネットワークに関わらずメッセージが流れることができるように、アプリケーションは、速度制御ができなくてはなりません。アプリケーション開発者にとって、メッセージのサイズが何バイトであるかを判断するのは、特に言語間においては困難です。その一方で、送信するメッセージの数を判断するのは難しくはありません。これによってサービスは、ネットワークフロー制御とアプリケーションフロー制御を裁定することが可能になるのです。アプリケーションの処理がネットワークより早い場合もあれば、ネットワークの速度がアプリケーションよりも速い場合もあります。latency)も安定したものになります。これもまた、アプリケーションの応答に寄与します。queues)を使用する必要もなくなります。これまで述べたように、RESTfulなWebサービスの大きな欠点は、(事実上)テキストベースとして実装されていることです。バイナリデータの送信には、データをBase64エンコードする必要があります。結果的に、すべてが2回シリアライズされることになります。本当に必要なのはバイナリです。アプリケーションにとって、特に数値に関しては、テキストよりもバイナリを処理する方がはるかに効率的です。余分な括弧や波括弧、山括弧がないからです。最後に、データがバイナリならば、フォーマット次第では、シリアライズやデシリアライズをゼロにすることも可能です。(SBE)やFlatbuffesなどを参考にしてください。これらはJSONを使うよりも、はるかに高速です。最後に、さまざまなトランスポート上でリクエストを送信できることが望まれます。RESTfulなWebサービスで通常使用されるHTTPはTCP上でのみ動作しますが、本当に望ましいのはネットワークの抽象化です。仕様に従ってプログラムするだけで、トランスポートを心配しなくてすむようにしたいのです。それと同時に、ブラウザと通信するアプリケーションは、WebSocket上で動作可能であるべきです。アプリケーションをデプロイする場所を変えるたびに、新しいネットワークツールキットにスイッチしなければならないのではたまりません。アプリケーションを変更しなくても、トランスポートを簡単に交換できるべきなのです。どのプロトコルが条件にかなうのか?RESTとHTTP/2がより適している、という人もいるでしょう。HTTP/2はHTTP/1より優れていますが、仕様を読む限り、その唯一の目的はよりよいWebブラウザプロトコルを作ることであって、マイクロサービスでの使用を目的として設計されたものではありません。その目的で、すなわち、サーバHTMLからWebブラウザへの通信手段として使われるべきです。繰り返しますが、マイクロサービスの通信を目的としたものではないのです。そもそも、これらのメソッドは、サーバ間通信を目的としたものではないのです。HTTP/2はストリーミングを提供しますが、サーバプッシュのみに限られます。RESTをHTTP/2上で使用するには、クライアントからリクエストを開始して、その上でデータをサーバにプッシュしなくてはなりません。HTTP/2のフロー制御はバイトベースのフロー制御です。これはWebブラウザには好都合ですが、アプリケーションには向いていません。アプリケーションで実行されている処理を対象としてアプリケーションフローを制御する手段については、依然として存在しないのです。最近はgRPCの利用に関して、多くのノイズがあります。gRPCは概念的にはSOAPによく似ていますが、サービス定義にXMLを使う代わりに、Protobufを使用します。SOAPと同じように、URLとヘッダマジックの寄せ集めなのですが、こちらではHTTP/2を使用します。これはつまり、gRPCが、ブラウザ用に設計されたHTTP/2と強く結び付いているという意味です。悪いことに、Webブラウザではサポートされていません。それどころか、gRPCコールをRESTコールに変換するためのプロキシが必要であるため、それを使う目的さえも失われます。ここで明らかになるのは、gRPCの設計の貧弱さです。HTTP/2をプロトコルとして使用するのか、なぜブラウザで動作しないのか?その本来の目的によって永遠に制限を受ける上に、意図したところでも使用できないのです。ここから次のポイントである、RESTの最大の制限はHTTPと結び付いているという事実にある、という点につながります。必要なのは、サービス間通信用に設計されたプロトコルです。サービス間通信を目的として特に設計されたプロトコルを使用することで、極めてシンプルで、より信頼性の高いアプリケーションを開発することができます。ハックや回避策、インピーダンスのミスマッチは存在しません。建設資材に例えてみればよく分かります。小さな橋を造るのには木材が最適です。小さな川を越えるためであれば、それで何の問題もありません。それを使ってもっと長い距離を渡ろうとすると、事態は複雑になってきます。木製の橋でも成功したものはあります。よい資材で作られた近代的な橋と比較すると、失敗する確率が非常に高かったのです。非常に複雑で、建築にもずっと長い時間が必要でした。現在、鉄筋とコンクリートが使われている理由はここにあります。メンテナンスが用意で、建築費が安く、より長い距離を渡すことができるのです。最新のサービスを開発するために、HTTPの代替となる最新の素材が必要です。オープンソースのRSocketはサービス用に設計され、アプリケーションレベルのフロー制御を内蔵した、コネクション指向のメッセージ駆動プロトコルで、ブラウザ内でもサーバ上でも同じように機能します。実際にWebブラウザで、マイクロサービスのバックエンドへのトラフィックを処理することも可能です。テキストでもバイナリデータでも同じように機能し、ペイロードの断片化が可能です。アプリケーションがネットワークプリミティブとして実行する、すべてのインタラクションをモデル化します。アプリケーションキューをセットアップしなくても、データのストリームやPub/Subを実行できるのです。RESTは理にかなった、まっとうなソリューションです。問題があるのはマイクロサービスです。分散システムは、それ自体でも十分に難しいのですから、そのために設計されたものでないものを使うことで、さらに複雑にするようなまねはしたくありません。Roeser氏はNetifiの共同創設者でCEOです。NetflixとNikeで大規模な技術プロジェクトを率いてきた、分散リアルタイムで10年のキャリアを持つベテランです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。