あなたはグーグルではありません

プログラマーは、何らかの理由で時々夢中になります。 そして、いくつかの完全にばかげた理由のために。 私たちは自分たちを超合理的な人々と考えるのが好きですが、新製品のキーテクノロジーを選択することになると、ある種の狂気に陥ります。 突然、誰かが1つのクールなものについて何かを聞いたことがわかり、彼の同僚はHabréの別のコメントを読み、3人目の人は他の似たようなものについてのブログ投稿を見ました...性質が完全に反対のシステム間で選択しようとする試みで、私たちが一般的に選択しようとしていることとその理由をすでに忘れています。



合理的な人々はこのように決定を下しません。 しかし、これはプログラマーがMapReduceのようなものを使用することをしばしば決定する方法です。



ジョーヘラースタインが生徒にこの選択についてコメントした方法は次のとおりです（54分目）。

事実、世界には現在、同様の量のデータを処理する約5社が存在します。 他の誰もがこのデータをすべてやり取りし、フォールトトレランスを実現しますが、これは本当に必要ありません。 人々は2000年代半ばからギガントマニアとグーグルに苦しんでいます。「世界最大の（将来）データ処理サービスの1つを構築しているので、Googleと同じようにすべてを行います！」

データセンターの階数は？ Googleは現在、オクラホマにあるこのような4階建ての建物を建設中です。



あなたが本当に必要とする以上の弾力性を得ることは良い考えのように思えるかもしれません。 しかし、これは、自動的かつ無料で発生する場合のみです。 しかし、これはそうではなく、すべてに独自の価格があります。ノード間で大幅に多くのデータを送信するだけでなく、それを支払うだけでなく、古典的なデータストレージシステム（すべてのトランザクション、インデックス、クエリオプティマイザーなど）のハードグラウンドから一歩踏み出します.d。）新たなシステムの脆弱なインフラストラクチャーの不安定な場所。 これは重要なステップです（多くの場合、 後退します ）。 何人のHadoopユーザーが意識的に作成しましたか？ そのうちの何人が、これがよく考えられた賢明な動きだったと言うことができますか？



この点でMapReduceとHadoopは批判の対象となりやすい。なぜなら、貨物カルトの信者でさえ、彼らの儀式が何らかの形で航空機を引き付けるのにあまりうまく機能しなかったと最終的に認めたからである。 しかし、この観察結果は一般化できます。大企業が作成したテクノロジーを使用することに決めた場合、この決定に意識的に至らなかった可能性があります。 巨人の振る舞いを模倣することが可能であるという事実に対する神秘的な信念があり、それが同じ高さに達したことがこれにつながった可能性は十分にあります。







はい、これはもう1つの「反カーゴカルト」記事です。 しかし、待って！ 詳細な情報に基づいた判断を下すのに役立つ便利なチェックリストを以下に示します。

クールなテクノロジー？ さて、それをチェックしましょう。

次回、完全に素晴らしいテクノロジーを突然発見したとき、今日すぐにアーキテクチャー全体を書き直さなければならない場合、一時停止するようにお願いします。

1. 製品で解決する必要がある問題について考えてください。 最後まで理解してください 。 あなたの仕事は、いくつかのツールの助けを借りてこの問題を解決することであり、あなたの好きなツールが解決できる「いくつかの」問題を解決することではないはずです。
   
   
   
   
2. いくつかの潜在的なツールを選択します。 いくつかの選択肢のリストができるまで、自分用に「お気に入り」を1つ選択しないでください。
   
   
   
   
3. 各候補者について、彼の「 マスター文書 」を見つけて読んでください。 コメントや翻訳ではなく、「同じ」ドキュメント。
   
   
   
   
4. このツールの作成につながった歴史的背景を特定します 。
   
   
   
   
5. 理想はありません。 各ツールの長所と短所を比較検討します。 作成者が主な目標を達成するために必要な妥協点を理解します。
   
   
   
   
6. 考えて ！ 自分の目標と優先順位が、使用する予定のツールの作成者の目標と優先順位と一致するかどうか、誠実かつ正直に質問に答えてください。 このツールに関する新しい事実は、使用を拒否する可能性がありますか？ たとえば、タスクの規模は、アプリケーションの非合理性について考えさせるためにツールが設計されたものとどの程度異なる必要がありますか？

そして、あなたはアマゾンではありません

上記の方法論は非常に簡単に実践できます。 最近、私はある会社と、Cassandraを新しい（公正に読み込まれた）プロジェクトに使用する計画について話し合いました。 Dynamoの原理を説明した元のドキュメントを読み、CassandraがDynamoに十分に近いことを知って、これらのシステムは書き込み操作の優先順位付けの原理に基づいていることに気付きました（Amazonは「カートに追加」操作が常に成功することを望んでいました）。 さらに、従来のリレーショナルデータベースの一貫性と機能性の保証を犠牲にすることでこれを達成しました。 しかし、このソリューションのアプリケーションについて説明した会社は、データの書き込みを優先しませんでしたが（すべてのデータは1日に1ブロックずつ）、一貫性と効率的な読み取りが非常に必要でした。







Amazonは多くの異なる製品を販売しています。 「バスケットに追加」操作が突然不安定に動作し始めた場合-多くのお金を失います。 同じ状況ですか？



Cassandraを実装したい会社は、PostgreSQLのクエリの1つが数分間実行され、プラットフォームのハードウェア機能によって制限されると考えていたため、これを実行しました。 いくつかの明確な質問の後、ベースをSSDに移動すると、この要求が2桁（最大数秒）加速されることがわかりました。 もちろん、それでもまだ低速でしたが、SSDへの移行（2番目の問題）によってボトルネックを約100倍高速化できたことに感謝します。 アーキテクチャの基本的な変更なし。 Cassandraへの移行が正しい方法ではないことが明らかになりました。 データベーススキーマを再構築する可能性がある既存のソリューションを調整する必要がありましたが、RECORDINGの問題を解決するために作成されたツールによってREADINGの問題を解決しようとはしませんでした。

さらに、あなたはLinkedInではありません

私の知り合いの一人がカフカ周辺で彼らの建築をどのように決定したかを知ったとき、私は非常に驚きました。 これは私にとって奇妙に思えました。なぜなら、彼らの主な仕事は数十（良い日-数百）の非常に重要なトランザクションを処理することだったからです。 このような入力負荷の場合、「 祖母が紙のノートに手作業で書き込む 」というソリューションでさえ適切です。 Kafkaは、すべてのLinkedIn分析情報（これらのメッセージ、リクエスト、グループ、チャット、ニュース、評価などすべて）を収集するために作成されました。 大量のデータ。 現在、そのボリュームを推定することはできませんが、数年前、LinkedInは1日に1兆件のイベントを発生させ、個々のピークは1秒あたり最大1,000万件でした。 はい、1日あたり10件のトランザクションも正常に処理できることを理解しています。 しかし、なぜこれを行うのでしょうか？ 理論的な負荷と実際の必要性の違いは10オーダーです！







たとえば、私たちの太陽は地球よりも6桁大きいだけです。



はい、この会社のエンジニアがカフカのすべての利点を合理的に評価し、負荷に関係なく、私には未知の何らかの理由でこのツールを選択した可能性があります。 しかし、彼らは単に熱狂的なレビュー、記事、コミュニティの意見、または「カフカを取りなさい」と叫んだ何かの影響を受けただけの可能性が高いです...いいえ、まあ、あなたは10桁だと思います！

あなたはアマゾンではないことを述べましたか？

Amazonの分散データベースよりもさらに人気のあるものは、スケーリングに対するアーキテクチャアプローチであるサービス指向アーキテクチャ （SOA）です。 2001年、Amazonはフロントエンドの負荷を効果的にスケーリングできないことを認識し、この問題の解決に取り組んでSOAに取り組みました。 このサクセスストーリーは口頭で、あるエンジニアから別のエンジニアに書面で伝達され、3人のプログラマーとゼロユーザーの最初のスタートアップはすべて、ホームページをナノサービスに分割することでライフパスを開始します。 AmazonがSOAに移行する必要性を認識するまでに、 従業員数は7,800人で、年間30億ドル相当の商品を販売していました 。







この部屋は7,000人を収容します。 そして、AmazonにはSOAへの切り替えが必要なときに7800がありました。



SOAを実装するために7800人目の従業員が雇用されるまで待つ必要があると言っているのではありません。 自問してみてください-これは今解決する必要がある問題ですか？ 他に誰もいませんか？ これが真実であり、あなたの50人の会社がSOAの不在下で正確に休んでいると私に言ったら、何十倍もの大企業がこれに全く苦しんでいないという事実をどのように説明しますか？

そしてグーグル-グーグルではなく

HadoopやSparkなどの拡張性の高いツールを使用することは非常に興味深い場合があります。 ただし、実際には、従来の機器は通常の負荷やさらに重い負荷に適しています。 一見「大きな」ボリュームが1台のコンピューターのRAMに完全に収まることもあります。 今日、約1万ドルでテラバイトのRAMを入手できることをご存知ですか？ 10億人のユーザーがいる場合でも（1人ではない場合）、この価格の場合、ユーザーごとにRAMに1キロバイトのデータを取得できます。 非常に高速なキロバイトが利用可能です。 おそらくこれはあなたのタスクには十分ではなく、ディスクから何かを読み書きする必要があります。 しかし、ディスクの数はいくつですか？ ほとんどない。 GFSやMapReduceなどのソリューションは、インターネット全体の検索インデックスを保存するために少しの間作成されている必要はありません。







今日のハードディスク容量は、GFSの説明が発行された2003年よりも大幅に安価です。



GFSおよびMapReduceのドキュメントを読んだことがあるかもしれません。 そうすれば、Googleが解決しようとしていた主な問題は容量ではなく帯域幅だったことを思い出すことができます。 彼らは適切なデータにより速くアクセスするために分散システムを構築しました。 しかし、今日は2017年であり、デバイスの帯域幅は拡大しています。 Googleほどデータを処理する必要はないことに注意してください。 それで、より良いハードドライブ（たぶんSSD）を買うだけで十分かもしれません、それで十分ですか？



おそらくあなたは時間とともに成長することを期待しています。 しかし、あなたはどれくらい正確に考えましたか？ SSDのコストよりも速くデータを蓄積しますか？ すべてのデータが1台の物理マシンに収まらなくなるまで、ビジネスをどれだけ成長させる必要がありますか？ 2016年、1日に2億件のクエリを処理するStack Exchangeシステムは、スタックオーバーフロー用、他のすべて用、および2つのレプリカの4つのSQLサーバーのみを使用しました 。



上記のチェックリストに従って、HadoopまたはSparkで停止できます。 そして、それは正しい決断でさえあるかもしれません。 ただし、ここでの正しい決定が必ずしも長く続くとは限らないことを理解することが重要です。 Googleはこれをよく知っています。MapReduceが検索インデックスを構築するのに十分に機能しないと判断するとすぐに、使用を中止しました。

最初に問題を理解する

このアイデアは私のものではなく、決して新しいものではありません。 しかし、おそらくこの記事の解釈では、上記のチェックリストとともに、あなたの心に届くでしょう。 そうでない場合は、 ハンモック駆動開発 、 解決方法、または科学と工学の 実践などの資料を見ることができます-すべてに同じ思考が含まれています。問題を英雄的に解決する前に理解するようにしてください。 本G. Polyaには次のフレーズがあります。

知らない質問に対する答えを見つけようとするのは愚かです。 問題を解決できないものに取り組むのは悲しいことです。