デベロップメントオンラインゲーム開発に最適なプログラミング言語は何か?最近のゲーム開発者は、ゲームをより分かりやすく、魅力的なものにすることに注力しています。そのためには、最適なプログラミング言語を選択するという問題が生じます。すべての要件を満足する言語を選ぶのは簡単ではありませんが、JavaScriptのようなリーダに頼ることは可能です。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Kafkaは、マイクロサービスを基盤とするシステム内でのメッセージやイベントの配信によく使用される、スケーラビリティの高い分散ストリーミングプラットフォームである。これらのイベントは、複数のマイクロサービスに分散したビジネスプロセスの一部の場合もある。複雑なビジネスプロセスの処理には、ワークフローエンジンが使用できるが、Kafkaとマッチするためには、kafkaと同程度のスケーラビリティを提供できることが必要となる。Zeebeは、このようなスケーラビリティ要件を満たすべく、設計と開発が進められているワークフローエンジンである。Waehner氏が、Kafkaの特徴と、イベント駆動型アーキテクチャ(EDA)への適合性について説明した。Rücker氏は、ワークフローエンジンであるZeebeと、それをKafkaと併用する方法について述べた。ConfluentのテクノロジエバンジェリストであるWaehner氏は、現在Kafkaが広く採用されている理由として、統合されるアプリケーションやマイクロサービス、モバイルアプリやIoTデバイスの数が増え続けていることと、それに伴って、ますます多くのデータが提供されるようになっていることを挙げた。我々は以前よりも多くのメッセージを、以前よりも高速に、時にはリアルタイムのユースケースで処理しなければならない。この取り組みは何年も前に、ポイント・ツー・ポイント統合の構築によって始まったが、その方法はスケーラビリティに乏しく、メンテナンスも困難だった。10年ほど前から、統合手段としてエンタープライズサービスバス(ESB)が使用されるようになり、さらに今日では、すべてのアプリケーションを接続する、Kafkaなどのメッセージストリーミングプラットフォームに置き換えられている。EDAは新しい考え方ではない。その概念は、少なくとも10~20年前には存在していた。新しいのは、データを処理する方法だ。データベースに格納したデータを他のサービスが読み取って処理する、という方法ではなく、現在ではデータが流れて、継続的な処理が行われる。イベントストリーミングプラットフォームの重要な差別化要因は、SQLやNoSQLデータベースのような静的ストアを使用しないことだ。その代わりに、イベントやその他のメッセージが保存される。これはアプリケーションの構築方法にも影響する。現在では、イベントがパブリッシュされ、他のアプリケーションによってコンシュームされている。Kafkaには3つの概念がある、とWaehner氏は指摘する。メッセージング、データ保存、データ処理である。それは他の多くのブローカのようなメッセージングブローカであり、望む限りデータを保存できるストレージシステムであり、最終的に実行可能なデータ処理だ。Kafkaとデータベースに共通する重要な機能は、次の2つである。メッセージの厳密な順序付け。これは多くのユースケースにおいて非常に重要である。メッセージはすべてディスクに保存されるので、クラッシュしてもデータを失うことはない。Kafkaでもうひとつ重要な点は、分散を前提に設計され、障害を考慮して構築されていることだ。その中心をなすのは、レプリケーション、フォールトトレランス、パーティショニング、エラスティックスケーリングなどの概念である。Waehner氏の見解によると、多くの開発者は、Kafkaを単なるメッセージングプラットフォームとして見なしている。それに対して氏は、さらに2つのコンポーネントが含まれていることを指摘する。Kafkaのコア上に構築された統合フレームワーク。コネクタの例には、多数のデータベースとメッセージングシステムが含まれる。ストリーム処理を目的とする。Waehner氏はこれを、最も簡単なデータ処理の方法だと考えている。Waehner氏は、Kafkaをコアビジネスアプリケーション構築に使用する事例がますます増えていることから、Kafkaがビジネスとして成立していることを指摘し、自身の講演の結論とした。ビジネスの分析は依然として重要だが、それはごく一部に過ぎない。氏が目の当たりにするもうひとつのトレンドは、顧客の大部分がハイブリッドであるということだ。新たなシステムはクラウド内に構築されるが、オンプレミスにもシステムが残っており、それらすべてが相互に通信する必要がある。Rücker氏Camundaの共同創設者でデベロッパ・アドボケートのRücker氏は、ここ数年間、氏の顧客の間にマイクロサービス採用の明らかなトレンドがあることを実感している。氏は、一部のユーザがイベント駆動型のアプローチの導入を始めて、現在では全面的に採用している、という点にも注目している。イベント通知パターンを使用したシステムが、ビジネスのさまざまな部分を担当するマイクロサービスで構築されているのだ。これらのサービスは、発生した事象を他のサービスに通知するために、イベントを発行する。ビジネス機能を実現する上で、いくつかのサービスが関与して、相互にイベントを送信する場合もある。Rücker氏はこれを"ピアツーピアのイベントチェーン"と呼び、その問題点のひとつとして、ビジネスの観点から全体的な流れを把握することが困難である点を指摘する。Fowler氏の記事にも言及している。イベントの流れを把握するためのアプローチのひとつは、モニタリングとトレースを活用することだ。Rücker氏はInfoQの記事で、これをどのように行うことができるか、実例を挙げて説明している。氏が推奨するのはプロセス追跡の方法である。ワークフローをモデル化し、全イベントを監視するワークフローエンジンを使用することで、各イベントフローが正しく機能していることをビジネスの観点から確認すると同時に、障害発生時には通知を代理で受け取ることが可能になる。プロセストラッキングは何も変更する必要がなく、適用が簡単だ、とRücker氏は述べている。ワークフローエンジンを、Kafkaインフラストラクチャに接続すればよい。同時にこれは、例えばプロセス終了に時間がかかり過ぎている場合にタイムアウトや警告を追加するなど、潜在的な障害に対処するための最初のステップにもなる。プレゼンテーションでは、Vodafoneが既存ミドルウェアのリプレースを実施するにあたって、最初にトラッキングを導入し、その後すべてのタスクをステップバイステップでオーケストレーションに置き換えていった実例が紹介された。ピアツーピアのイベントチェーンでの潜在的な問題は、ワークフローを変更する必要がある時だ。このような場合には、いくつかのサービスに、自身のイベントサブスクリプションを変更する必要性が発生する可能性がある。チーム間やサービスのデプロイメントの調整,あるいは実行中のワークフローとシステム内のアクティブなイベントに関する考慮も必要になる。ビジネスプロセスが確実に遂行されるようにするために、Rücker氏は、エンドツーエンドの責任をひとつのサービスとして抽出する方法を好んで採用している。メリットは、企業にとって非常に重要なことの責任をひとつのサービスが負うことと、タスクのシーケンスを制御する単一ポイントが存在することだ。ワークフローを制御するためのコマンドも使用できるようになる。何かをするように指示するという意味において、コマンドはオーケストレーションに他ならない。Rücker氏は、オーケストレーションはマイクロサービスの内部であって、すべてのサービスが使う中核的インフラストラクチャメカニズムではない、と指摘する。氏は、ひとつのサービスがワークフローを担当することにより、実行中の要求の状態や、成功した要求の数などを確認する単一のポイントが存在する、という点も指摘している。Camundaは現在、水平スケーラビリティを備えたマイクロサービス用のワークフローエンジンであるZeebeの開発に取り組んでいる。これは、Kafkaと組み合わせることで、低レイテンシかつ高スループットのユースケースに適している。現在はまだ開発者向けプレビューの状態だが、毎秒10~20万のワークフローインスタンスを実行中のパイロットユーザがある。Rücker氏によると、実運用対応バージョンは2019年7月に予定されている。プレゼンテーションで使用されたWahner氏のスライドとRücker氏のスライドは、いずれも公開されている。InfoQとのインタビューの中で、Rücker氏は、企業にとって非常に重要な受注処理がコアドメインで処理されないというのは奇妙な話であって、イベントの監視によって処理の滞りを検出可能であるべきだ、と述べている。注処理サービスは、注文発生時にイベントを発行して、他のサービスが支払い処理や顧客への商品配達を行ってくれることを単に期待するのではなく、注文の履行という観点での考慮が必要である、というのが氏の考えだ。我々はイベントストリームをよく話題にするが、レコードあるいはメッセージストリームを語ることが重要だ、とRücker氏は考えている。APIで使用されている用語はイベントではなく、レコードなのだ。Patterns"を紹介している。同署ではCommandやDocument、Eventといったメッセージが解説されている。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。