3つのマイクロサービスストーリー、またはエンタープライズ向けMSA

マイクロサービスの考え方は、専用の機能を備えた小さなサービスのセットとしてアプリケーションを構築することであり、それぞれが独自のプロセスで動作します。 このアプローチにはいくつかの利点がありますが、これは今日の話のトピックではなく、マイクロサービスアーキテクチャの考え方がロシアの企業ビジネスと企業のITマネージャーの観点からどのように見えるかです。





イゴール・ベスパルチュクと一緒に、この傾向を3つの異なる角度から見ようとします。これは、私たちが扱っているものの性質を理解するのに非常に役立ち、その結果、正しい結論を導き、正しい決定を下すために役立ちます。



マイクロサービスは、Webスケールアーキテクチャの最も重要かつ重要なコンポーネントの1つです。これは、エンタープライズでの技術とパターンのデバイスの再設計に最も大きな影響を及ぼします。 技術自体がどこにあるのかを今言うのは困難です-おそらく最高のピークであり、私たちはさらに10回あきらめなければなりません。 しかし、それにもかかわらず、これは今それを勉強しない理由ではありません 。



スピーカーについて： Igor Bespalchukは、 CUSTISグループのアプリケーションアーキテクトであり、大企業や政府機関向けのカスタムソフトウェアを開発しています。 これに先立ち、イゴールは企業や小売店とも協力していたため、企業部門で開発プロセスがどのように行われているか、管理システムがどのように機能するか、特定の変更が徐々に漏れていることを観察する機会がありました。



次に、 Web-Scale IT Conference 2017でのIgorのレポートの転写です。

MSAテーマの紹介

マイクロサービスアーキテクチャに初めて出会ったのは2012年11月で、 ジェームスルイスによるQConの素晴らしいプレゼンテーションに出会ったときです。 彼は、膨大な量のデータを含む大規模で複雑な、ロードされたプロジェクトでどのように機能したかについて話しました。 建築デザインの実践を含め、驚くほど珍しいことで、想像力を直接刺激しました。 そして同時に、これは、長年にわたってモノリシックシステムで実践してきたドメイン駆動設計 （DDD）の概念とも強く交差していました。







そして2014年、 Martin Fowlerのウェブサイトに大きな記事「Microservices」が掲載され、そこでマイクロサービスとは何か、なぜ必要なのかを明らかにし、ロシア語に翻訳されました 。







簡単に言えば、以前は異種機能を一緒に使用していましたが、1つのシステムまたはアプリケーションがあり、1つのプロセスとして実行されていました。 システムのスケーリングが必要な場合、これは水平スケーリングによって行われましたが、機能全体で均一に行われました。



要するに、マイクロサービスの中心的な考え方は、DDDで呼び出されるように、別のプロセスに別のタイプの機能- 境界付きコンテキストを配置し始めるということです。 必要に応じて、これらのピースは個別のプロセスで分離されるため、これらのピースを個別にスケーリングできます。 5、10、または20を実行できます-必要な数、製品カタログ、ユーザー認証ブロックなど。



以前に設計されたサービスと比較して、非常に小さいことがわかりました。



このアプローチにはいくつかの利点がありますが、これについては少し後で説明しますが、一般的にこれは今日の話題ではありません。



2014年から2015年にかけて、ロシアの企業部門でそのようなアーキテクチャを使用した生活経験があるかどうかを調べることにしました。 それから私の友人や同僚の間には何もありませんでした-理論的にチャットするのは面白かったですが、誰も練習していませんでした。



2016年、「何か」が始まりました。 一部の銀行では、「マイクロサービスアーキテクチャを使用しようとしています。Dockerなどがあります」と聞くことができます。 それが何から来たのかが面白かった。



2017年、CUSTISでMicroservices for Enterpriseという会議を開催することにしました。 これは半閉鎖的なイベントで、ほとんどがエンタープライズの馴染みのあるアーキテクトと呼ばれていました。



この会議では 、特にIT管理者からの誤解がまだ多いことが判明しました。 彼らはなぜこれが必要なのか全く理解していません。 彼らには、これはある種の「プログラマーの別の発明」であり、不必要なトラブルにすぎないようです。 そのため、私はもう一度この現象を、技術者ではなく、ITディレクターまたは開発ディレクターの立場にある人々がよりよく理解するという観点から見ようとしました。 まあ、あなたが技術の専門家なら、おそらくこの話は 、マイクロサービスのアプローチの意味と利点を経営者に説明するのに役立つでしょう 。

オンライン関心

近年のマイクロサービスのトピックに対するネットワークへの関心が非常に高まっているという事実に、あなたは長い間立ち止まることができません。





2014年以降、特にマイクロサービスに関するいくつかの国際会議が開催されています。





このトピックに関する膨大な文献が見つかりました。







情報は単なる倉庫ですが、それにもかかわらず、ロシアの企業党では、総質量を見ると、彼らはそれについて話し始めているところです。 もちろん、すべてが異質です-どこかでアプリケーションの実践がより大きく、どこかより少なく、どこかまったく眠らず、精神もありません。



したがって、私はこのギャップを埋めようとしています。



私のストーリーは、 3つの異なる開発ストーリーとして構築されます。 一緒にこの傾向を3つの異なる角度から見ようとします。 これは私たちが扱っているものの性質を理解し、その結果、マイクロサービスの傾向に関して正しい結論を導き、正しい決定を下すために非常に役立つように思えます。

最初の話。 2つの世界としてのエンタープライズとWeb

最初の話では、システムエンジニアリングの場合と同様に、外部から内部に進み、市場とニーズについて話します 。 エンタープライズとWebの2つの世界についてです。





2014年、 ガートナーは、2017年までに主要企業の50％が間違いなくWebスケールアーキテクチャを使用する必要があると述べた分析レポートをリリースしましたが、その内容はまったく明確ではありませんでした。 Web規模のIT会議を開催することを決めたとき、Web規模のテクノロジーとは何か、エンタープライズとは何かを判断し、どういうわけか違いを理解しようとしました。

開発パス

それから私は自分でそのような絵について描きました。 条件付きの「Web」と条件付きの「エンタープライズ」は、2つの大きな産業、または産業の2つの大きなセグメントです。今日のITの観点から見ると、開発パスが大きく異なるため、外観が大きく異なります。

• 企業は、主に有形の商品とサービスを提供する古典的なビジネスから発展してきました。ITは、このビジネスを自動化する手段として存在します。
• Webでは、最初から製品とサービスの両方がデジタル形式であることが多く、Amazonの場合のように、サービス自体の非常に大きなシェアはデジタルです。

当初、これら2つの世界はほぼ完全に分かれていました。 インターネットは孤立したもののように見え、10〜20年間、この島自体に大きな進化の圧力がかかっていました。

ウェブ進化の圧力

• 物理的な成長制限の欠如

新しい店舗を開くために不動産を購入する必要はありません。

• デジタルを含む新しいタイプのサービスの爆発的な成長 。

このインターネットの勇敢な新しい世界では、写真を交換することができ、一般的に、神は多くの種類の新しいサービスがあることを知っています。 これは爆発的な成長と激しい競争につながりました。

• 領土の場所に関係なく、全世界をカバーする無制限の顧客を求める激しい競争 。

さらに、これは近隣の通りの競合他社との戦いではなく、インターネット空間に代表されるすべての人々との戦いであるため、ユーザーインターフェイスを含むサービスの品質を改善する必要があります。

• UI / UX、ロードとスケーリング、開発の要件。

これは、 ユーザーエクスペリエンスの専門化が登場した場所です。 以前はこのようなものはありませんでした。 企業ソフトウェアでは、ユーザーインターフェイスの使いやすさは、特に雇用された従業員にとって、望まれるものが多く残っていました。 また、負荷、スケーリング、開発の要件が増加しました。 テクノロジーの実行に追いついていない場合、あなたは死にます。

• テクノロジーの頻繁な変更、したがって、安定した同種のインフラストラクチャとアーキテクチャスタイルには、形成する時間がありません。

この世界では、雨の後はすべてがキノコのように成長し、インターネット企業はエンタープライズのように安定した同種のインフラストラクチャと何らかのアーキテクチャスタイルを形成する時間がありません。 この時点で、すでにいくつかの大きなパターンがありました。アーキテクチャスタイルは、主にベンダーの開発によってサポートされています。このベンダーのデータベースとサーバーラックがあり、これは何十年も変わっていません。

• オープンソースの開発の波、重いベンダーのカルトは形成されていません。
  
  

インターネットの世界ではすべてが本格的でしたが、ベンダー文化は形成されませんでした。 すべてをゼロから構築できます。

• 結果：これらの要件を満たす多くの技術的および組織的パターンを作成することで生き残ったものもありました。
  
  

進化プロセスの結果として、 生き残ったものになりました 。 そして、これらの最も厳しい要件を満たす特定の組織的、管理的、技術的慣行を生み出すことができたという事実により、彼らは生き残りました。

本土市場の衝突

正当化されると思われる古典的なビジネスの利益と恐れは何ですか？ 衝突する2つの大陸の比phorが好きです。





本土のエンタープライズがありました-ゆったりと進化した、自動化を備えた古典的なサービスの市場です。 そして突然、別の大陸が衝突していることが判明しました-進化プロセスも進行している別の世界が、独自のペースで進んでいます。 そして、おなじみのエンタープライズ世界の住人である私たちにとって、この進化プロセスの結果は、写真のようにあまり友好的ではないことが判明するかもしれません。



Googleが自動車、Airbnb（ホテル、Amazon-オフラインショップなど）をどのように扱っているかはすでに見てきました。



したがって、企業のIT部門として、またはエンタープライズワールドの請負業者として、これらの要素に注意を払わなければ、後悔することができます。



インターネットの巨人がどのように機能するかの技術的な側面を分析し、彼らはWebスケールアーキテクチャの一部である多くの異なるパターンとメカニズムに名前を付けています。







私の意見では、マイクロサービスは最も重要で、複雑で、重要なコンポーネントの1つであり、エンタープライズでの技術とパターンのデバイスの再設計に最も大きな影響を与えます。

最初の話の概要

もちろん、他のイノベーションと同様に、マイクロサービスの話題は誇大広告の時代から逃れることはできません。 喜んで経営し、お金で紹介する企業があります。そのため、すべてがねじれ、高い期待が生じます。







技術自体が現在どの領域にあるのかを言うのは困難です-おそらく予想の最高のピークであり、私たちはそれをさらに10倍あきらめなければなりません。 しかし、それにもかかわらず、 これは今それを勉強しない理由ではありません 。



市場とニーズに関する最初の話を要約すると：

1. MSAは 、Webテクノロジーの「パラレルワールド」での激しい競争の過程で生まれた技術的パターンの1つです。
   
   
2. 多くの点で、この「パラレルワールド」では、以下を提供することを学んだ人たち：
   
   
   • 高品質のサービスを備えたオンラインクライアントの保持 ;
   • エンタープライズにとって完全に一般的ではない高負荷とデータ量 。
   • 技術の急速な変動、ベンダーからの独立。

これらは、マイクロサービスアーキテクチャがエンタープライズにもたらす可能性のある利点です。 あなたのビジネスのある分野であなたがインターネット企業と競争する必要があると思っている、または考えているなら、あなたは彼らの技術を借りて自分でそれらの分野にそれを適用し、コンピテンシーを構築し、同じタスクを設定する必要があるかもしれません-負荷と変動性を高めます。 そうでなければ、彼らは単にそれを食べるでしょう。



3.彼らはすでにここにいます。

あなたがあなたがエンタープライズの世界から来ているなら、あなたは、どれだけ活気があり、ダイナミックで、私たちが古典的なエンタープライズで扱っているものと違っているのを見るでしょう。

セカンドストーリー。 エンタープライズソフトウェアのアーキテクチャスタイル

私たちは再び外に出ます-内部：市場から、つまり別の企業の環境から、この別の企業への機器の設置に進みます。 エンタープライズソフトウェアのアーキテクチャスタイルがどのように変化したか、ITがエンタープライズで一般的にどのように構築されたかについて話しましょう。

建築様式の開発

他のシステムやパターンと同様に、企業におけるITの開発は問題から問題へと進みます。 特定のパターンによる1つの問題を解決し、多くの場合、他の問題をもたらします。これは避けられないパスです。 さらに、私たちは常に単純なものから複雑なものへと移行します。これらは開発の一般的な法則です。



かつて、同僚と私はこれがいかにそうであるかを議論していたので、私たちは常に人々にとってそれをもっと簡単にしたいと思っています。 それどころか、すべてが複雑になっているのはなぜですか？

技術的なシステムを含むシステムの複雑さは、時々見られるように決して減少しないという理解が生まれました-それはインフラストラクチャの形で「 沈殿 」します。

つまり、多くの労働時間で戦わなければならなかったもので、ある時点でインフラストラクチャとして受け取ることがありますが 、時には適用されたタスクに無関心です。 この「堆積物」は常に増加していますが、システムの複雑さは時間とともに増大します。







むかしむかし（おそらくあなたは、私のようにこれらの時代を見つけられなかったでしょう）、企業のすべてのITは1台の大きなコンピューターで行われていました。 インフラストラクチャからは、ハードウェア、オペレーティングシステム、およびファイルのみがありました。 計算に必要なその他すべて（データストレージ、計算ロジック、コマンドラインインターフェイスなど）、前任者は自分の手で書く必要がありました。







時間の経過、IT能力の変化、そして今ではすべてのテーブルにパーソナルコンピューターがあり、共通データは何らかの形でネットワークに接続され、共有ファイルサーバーに保存されています。 インフラストラクチャにはさらに多くの機会があります。ネットワークに自分でアクセスする方法はまだわかっていません。ファイルサーバー上のファイル、最初のデータベースなどを操作するためのツールがあります。



しかし、もちろん、まだ複雑なタスクを手で書いています。データベースに何かを保存する必要があります。 ビジネスロジックを計算する必要があります。 すでにより複雑なグラフィカルインターフェイスなどを作成します。







次のステップは、リレーショナルデータベースです。 エンタープライズスタイルのITが、アーキテクチャスタイルとしてクライアントサーバーアーキテクチャに従って構築されたのは長い期間がありました。 これはすべてのベンダーによってサポートされていました。ここにデータベースがあり、ここにクイック開発ツールがあります。



これは、前のステップで手作業で書いた「一部の堆積物に陥る」インフラストラクチャへの複雑さの一部です。 箱から取り出しますが、常に十分な作業があります。 ますます複雑な構造のデータスキームを作成し、クエリ言語はより抽象的になり、SQLが登場しました。 ビジネスロジック、ユーザーインターフェイスなどを開発します。







しばらくして、 3層アーキテクチャが企業ソフトウェア開発者の心と関心を獲得しました。 たとえば、表示の場合、ブラウザおよびコンポーネントのライブラリの形式で、わずかに多くの空白があります。 それにもかかわらず、多くの手作業が残っており、膨大な数の統合タスクが発生します。 アプリケーションサーバーは主に統合に関与しますが、拡張が容易です。







このプロセスは続きます- サービス指向アーキテクチャ 。 企業のITは、B2Bシステム、特殊なWebサーバー、企業バスでさえ、ある時点でWebに移行し始め、これらすべてのシステム間の複雑な対話プロセスを調整するためのシステムを相互に統合しているようです。 そして、物語が繰り返されるたびに-箱から出して何かを手に入れますが、それでも私たちは手で多くのものを追加します。

機能の分離

このような回顧の後、意欲的なタスクが増えるたびに、その複雑さと非機能要件が増大していることに気付くことができます。 その結果、ITシステムは細分化し始めます。

• 地方分権化は有益になっています。
• 個々の機能の自律性を向上させます。 1台のクライアントコンピューターがクラッシュした場合、データベースは正常な状態のままです。
• パフォーマンスのスケーリング。 簡単に拡張できない非弾性システムは、もはや誰も満足しません。
• コンピューティング機能の専門化。
• 共有の統合 。 多数の切断されたすべての部品の統合には、別の専門化が生じます。

このプロセスは、3層のサービス指向アーキテクチャで突然停止しないと簡単に推測できます。 私の仮説は、マイクロサービスアーキテクチャで正確に継続するということです。



現時点では何がありますか？

• 私たちが戦うクライアント 、および使いやすさの要件が高まっている従業員には、さまざまなデバイス（ブラウザー、モバイルデバイスなど）が付属しています
• ビジネスタスクを実装するアプリケーションサービスはまだ残っています。
• データベースは特殊で共有されています。 すべてがうまく機能しない1つのユニバーサルデータベースに満足できなくなりました。 少なくとも、一方を非常に高速にし、もう一方を非常に大きくする必要があります。
• アプリケーションをさまざまなプラットフォームに適応させるために、特殊なノードが表示されます（ アプリケーションレベルのゲートウェイ ）。
• オーケストレーションとメッセージングに関連する開発が依然として必要です。

1つのアプリケーションに含まれるさまざまなサービスは驚くべきもので、恐ろしいものです。



さまざまなアプリケーションに必要な共通サービスがクラウドから提供されるようになりました。たとえば、認証フォームがあります。 それは少し脳を吹き飛ばしますが、それは開発の同じ原則に従います-それは際立っていて、特化して、いくつかのインフラストラクチャに属します 。



以前は責任のあるシステムごとに手作業で行わなければならなかった膨大な数の機会が、今ではますます多くの場合、あらゆるサービスに対して普遍的に行いたいと思っています。 繰り返しますが、自動スケーリング、システム監視、高可用性、ロギングに関連するすべてを「すぐに」提供することを本当に望んでいます。これは、すでに集中化されている必要があります。何が起こった。



つまり、同時にインフラストラクチャに対する巨大な需要があり、ゆっくりと遅れて、それを提供するベンダーの市場が引き上げられています。



実際、インフラストラクチャタスクがいくつ発生するかは驚くべきことです。 これは本当に膨大な量の作業です。たとえば、Avito は 、マイクロサービスの監視システムの作成は1人年の作業であると語っています。



約5年後も、さまざまなメーカーのマイクロサービスをすぐにサポートするための優れたインフラストラクチャが見られると思います。 しかし今のところ、それはまだ十分に未加工です。 それなしではありませんが、 インフラストラクチャはより厚くなり、サービスと機能はよりきめ細かくなっています 。







興味深い瞬間が起こっています。 ユーザーがあなたのもとに来て特定のデバイスとやり取りを始めたとき、「アプリケーション」とは何とも言えません。 以前は、企業にはさまざまなアプリケーションがあり、それらの境界は明確に理解されていました。



ユーザーはあるデバイスからログインし、別のデバイスからログインします-これは同じアプリケーションですか？ 私たちは内陸に見えます-いくつかのApp Gwがあり、それらは異なるサービスと相互作用します。 アプリケーションはどこにありますか？ しばらくすると、アプリケーションの概念が非常に曖昧になる可能性があるという感じがあります 。



おそらく、ビジネス機能の境界のみがこの混乱を何らかの形で抑制します。 そして、多数のインフラストラクチャサービスが存在する場合、それらを作成するのは愚かです。 システム内のすべてがビジネス機能に厳密に結び付けられるわけではなく、明らかに、企業の一般的なインフラストラクチャで行われます。 しかし、今ではそうではありません。今後5〜10年でおそらくそうではないでしょう。



このプロセス全体で非常に興味深い点ですが、特定の媒体または大企業でさえ、マイクロサービスとそれに伴う合併症のすべてが必要ですか？ たぶん、あなたは待つことができて、この山を登らないでください？

一般的なボートの問題

幸運にも不幸にも、 このプロセスから飛び出すことはうまくいかないと思います 。 これは私たちよりも強い傾向であり、すべてを運びます。 私たちには選択肢があります-しばらく待つか、統合するかのどちらかです。



問題は、企業全体で新しいインフラストラクチャスタイルが出現し始めているため、企業が特にそれを必要としていない場合でも、新しいアーキテクチャに向かって押し進め始めていることです。 たとえば、非常にスケーラブルなシステムとビッグデータは必要なく、比較的小規模なビジネスでうまく機能します。 これにより、おそらく、Delphiの2層アプリケーションが落ち着いて対処しています。



しかし、技術を開発するベンダーや研究者の注目の焦点がすべてここに向けられていることが重要です。 これはあなたには直接関係ないようですが、業界全体がここで発展していることがわかります。



従業員の願望のベクトルもこの方向に向けられています。なぜなら、それは流行であり、誇大広告であり、本、会議、その他すべてのものだからです。 この動きに何らかの形で統合しようとしない場合、しばらくすると、新しいショットではまったく気にならない非常に具体的なショットで作業する必要があることに気付きます。 これらが悪い労働者だと言っているのではありません。 しかし、少なくともある程度トレンドに従っていなければ、非常に優秀な人々があなたから洗い流されます。



したがって、遅かれ早かれ、実際にそのように感じていなくても注入する必要があると思うので、企業内で管理された方法で行う方が良いと考えています。 つまり、 戦うことがすでに不可能な場合 、 リードすることです 。

第二話のまとめ

企業における建築様式の進化の歴史を要約すると、次のことを記録できます。

• MSAは、複雑なエンタープライズソフトウェアシステムのアーキテクチャスタイルの開発における次のステップです。
• MSAは、以前のロジックである、特殊化、粒状化、および共通インフラストラクチャの割り当てに向けた一般的な動きを継続しています。
• 以前のすべての手順と同様に、MSAは以前のスタイルで発生した問題のいくつかを解決し、多くの新しいスタイルを生み出します。 これで何もすることはできません。あなたはそれと一緒に生きなければなりません-マスターしてもう一度やり直してください。
• もちろん、無料の朝食は発生しません！

第三話。 建築家の役割と専門分野

そしてさらに深くなります。 市場と、なぜそれについて考える必要があるのか​​、そしてそれがWebスケールの一般的な傾向にどのように適合するのかについて話しました。 次に、マイクロサービスアーキテクチャのトレンドに関連して、アーキテクトの役割と専門性がどのように変化するかについてお話したいと思います。







むかしむかし、ソフトウェア開発は開発チームと、作業とリソースの両方を管理する最大1人のマネージャーによって管理されていました。 システムが大きい場合、アーキテクチャを気にせず（かつてソフトウェアに関連するそのような言葉がなかった場合）、それを管理しなかった場合、「それ自体で何らかの形で」成長し、その後、強化され、管理し始めることが突然明らかになりましたあなたの場所であなたのプロジェクト。



アーキテクトの位置がまだ必要であることが明らかになりました、私は繰り返します-比較的大きなシステムで。



大企業内では、まだ少し複雑です。







最初は、いくつかの独立したsamopisnyシステムで管理していました。 その後、そのようなシステムが多数あることが明らかになりました。多くの場合、それらは既製のベンダーによって提供されており、相互に統合する必要があります。 ここでは、ソフトウェアアーキテクトだけの職業は不要になりましたが、次のシステムを実装し、小さな何かを完成させ、それをすべて結び付ける人のそのような特定のポジションが必要になります。 統合アーキテクト （統合ソリューションの専門家 ）の立場が現れ、 ソリューションの概念が生まれます。



これは、ソリューションアーキテクトがアナリストを超えて成長し、個々のソフトウェアのプログラミング方法を知らないが、大規模で複雑で有用な作業を実行できる人になることができる場合の興味深い専門分野です。



マイクロサービスが導入される前のこの期間に、企業のインフラストラクチャで通常どのように作業が行われるかは非常に興味深いです。 ほぼ完全にフェンスで囲まれ、個人のペースで、変化のライフサイクルの中で、すべてのエンタープライズアプリケーションに均一で標準的な非常に安定したインフラストラクチャを提供します。

-ここにOracleデータベースがあります。ここに仮想マシンがあります-仕事です。私たちは皆、厳格な標準でこれを順番にサポートしています。

IT- — , — - .



— — , .



, , :



最初のもの。 , , .



. , «, ». , .



, . , , IT.



. — , . , , , — .



, , , , , , .







, , , .



, , , , , . , , , , , , — , .



, . — , . , , , , «» , , - , «» .



, ERP . , , , . . , .



, , DevOps . , . , . , : - , . , - — , , . , , — , , .



. ITSM. , .



DevOps , .



, , , :

— , , , « ». .

. , , . — . , , , , , , , .

結論

. , MSA « Enterprise» , :

• Web Enterprise, , ;
• — , , ;
• , .

, , - MSA , — , , .



ニュース

- , enterprise web- Web-Scale IT — Backend Conf ++ , Whale Rider . , :

• 組織の変化への準備、または夢の先導者 /デニス・コチェルギン（フェアマスター）
• 大規模なITチームがすべての面で同時に変化し、死なないようにするにはどうすればよいですか？/アレクサンダー・アンドロノフ（ドド・ピザ）
• 誰が雲の上に住んでいるのか、またはクラウド固有のインフラストラクチャとは / Anton Weiss（Otomato）
• 誰でもアクセス可能な独自のクラウド：典型的なマイクロサービスのライフサイクルとkubernetesの依存関係 / Maxim Vikharev（Alytics）

レポートのステータスは4月中に更新されますが、最もクールなレポートを選択することをお約束します。そのため、待つ必要はありません。チケットを予約できます。