機知と勇気：iFunnyを作成したときに間違っていた回数

これは記事ではなく、フェイスブックです。 あなたがカットの下で読んでいるのは、主力製品であるiFunnyに関する5年間のすべての作業のための私たちのばかげたテクノミスの絞りです。 おそらく、私たちの物語は、間違いを避けたり、笑いを引き起こしたりするのに役立つでしょう。 どちらも良いです。 人々を笑わせる-FunCorpの職業は13年間です。

チームと製品に関するいくつかの紹介

2004年にペンザで学生として結成したチームのバックボーン。 長年にわたって、彼らはモバイルで何かをしました。 2010年、多くのシリーズで、AyDaPrikol-面白い写真を表示するためのiOSアプリケーションです。 特別な投資なしで、ロシアとCISの聴衆に届きます。

「なぜですか？」-私たちは考えており、2011年にはすでに北米市場向けのバージョンを作成しています。 最初の12か月で、App StoreとGoogle PlayのiFunnyは300万人以上によってダウンロードされており、5年後には米国で非常に人気のある本格的な娯楽ソーシャルメディア（ DAU = 3.5M）に変わります。

オーディエンスの主要部分は、iOSおよびAndroidアプリケーションのユーザーのままです。 すべての機能はそこで利用可能です。 しかし、 ウェブ版は視聴者とコンテンツの両方の面でアプリに徐々に追いついています。 ユーザーは毎日iFunnyに約40万件のミームを投稿し、6億件以上を閲覧しています。

「こんなに複雑なのは、普通の写真のリーフレット。 仕事の後にこれを行うことは本当に不可能ですか？」しかし、トリッキーなビジネスロジック（この場合はエンターテインメントロジック）を実装することに加えて、これは内部の重大な技術的課題でもあります。 ここで、たとえば、あなたは対処しなければなりません：

• ピーク時に15,000 RPSがバックエンドサーバーに到達し、60ミリ秒で応答を形成します。
• 1日あたり35億のイベントがデータウェアハウスで書き込まれ、分析されます。
• 1か月あたり5.5ペタバイトのコンテンツがCDNを介して配信されます。 ピーク時には、1秒あたり28,000リクエスト、つまり1秒あたり44 Gbpsです。

最初のバージョンでは、この記事の長さは22ページでした。彼らは、覚えていたすべてを収集しました。 その後、彼らはそれが今だけHabréにある別のファイルになることを決定し、最も特徴的なものを選択しました。ストレージとの混乱、DAUの計算エラー、MongoとのBDSMゲーム、視聴者の詳細について。 そしてちょっとした陰謀：まだ主流ではなかったときに、トランプとプーチンを結び付けました。

高負荷プロジェクト

iFunnyの前は、たくさんのプロジェクトがありましたが、接頭辞highloadのプロジェクトはありませんでした。 最も印象的なのは、毎日100,000人のユニークビジターが出席したことです。 ここですべてがあまりにも突然起こった。 負荷とデータ量に対応できなかったため、ホスティング事業者またはテクノロジーを定期的に変更しました。

次のようになりました。

それぞれの動きは、それ自体の理由によって引き起こされました。どこかが高価で、どこかが機能性に欠けていて、どこかは、Hetznerの場合のように、ホスティング自体が逃げることを余儀なくされました。 私たちはかなり機能不全の隣人であり、定期的にbeatられ、ユーザーのおっぱい/猫およびその他の解剖について正当な苦情を投げかけられました。

気づいたように、特に鉄から雲へ、そしてその逆に走ることができました。 ケースについては「戻る」で説明します。

障害物脱出

2012年の初めに、アプリケーションとデータベースはAWSにありました。まもなく、1つの10Gbpsサーバーからrsyncを使用した複数のサーバーへの困難なパスを経て、CDNを介してコンテンツの配信を開始します。

しかし、5月までに、AWS上の垂直にスケーラブルなMySQLが天井に置かれ、負荷がかかると失敗し始めます。 そして、これはRDSなので 、ノブをねじることはほとんどできません。 クラウドはまだ水平スケーリングに関するものですが、壊れているので、OVHに移行することにしました。OVHはコンテンツを配信する場合でも成果を上げました。

通常の開発者なら誰でも、アーキテクチャの変更、シャーディングについて考え始めるでしょうが、私たちは再び最小の抵抗、つまり垂直スケーリングの道を歩みました。 OVHでMySQLを最初に削除したこと。 パフォーマンスが向上しました。これは、仮想化ではなくハードウェアであり、オーバーヘッドが小さく、ディスクI / Oの微妙な違いがあるためです。 同時に、強力なハードウェア（8コアXeon、24 GBのRAM、300 GBのSSD）を使用しましたが、金銭的にはAWSよりも安価でした。

興味深い事実は後に明らかになりました。 ログを掘り下げると、1秒あたり50件のリクエストを送信するコンテンツを盗んだロシアのIPに気付きました。 これにより、APIバックエンド、特にMySQLに多くのストレスがかかります。 これらの要求が、OVHへの迅速な飛行の理由の1つになりました。 すべてを除外した後、データベースはさらに簡単になりました。すでに3回だけです。

1秒あたり50件のリクエストが数週間で新しいユーザーを襲撃する可能性があるため、それほど動揺しませんでした。 しかし、彼らは復pumpすることを決めました。ポンピングはすでに非常に厳しい方法であり、大きなページだったからです。 写真の代わりに、彼らはjpegを装った700メガバイトのUbuntaディストリビューションを送り返しました。 私たちは後悔していません-彼らは非常に怒っていました。 これは現在15,000 RPSのピークであり、「問題のある」50でしか笑えませんが、それは重要でした。

その結果、彼らは長い間OVHの能力を享受していませんでした。 移転の1年後、新しいサーバーの迅速な提供に問題がありました。 遅延は1か月に達しましたが、これは創業者の命中です 。 私たちは成長を続け、そのような政策に真剣に苦しみました。 彼らはAWSに戻ってきました。AWSにはすでに実証済みのソリューション、SaaS製品、そして最も重要なことには柔軟性があります。 厳しい企業にキャパシティプランニングを任せて、コードを書きましょう。 そして今、私たちは、最初はクラウドとSSDがなければ、私たちはまったく存在しないことをますます理解しています。 この記事のように。

現在、S3、Redshift、ELB、Route 53、CloudFront、ElasticMapReduce、Elastic BeanstalkのAWS管理サービスを最大限に活用しようとしています。 小さなチームの場合、これは解決策であり、より効率的に機能します。 しかし、これは魔法の技術の助けを借りて問題を解決できることを意味するものではありません。 私たちはすでに同じRedshiftを深く掘り下げました。私たちは徹底的にジブルトを研究しなければなりませんでした。 したがって、これはすべて、NoSQLのように、決して特効薬ではありません。 ささいなことを理解する必要があります。

急成長

FalseDAU

すべて同じ2012。 技術の混乱とheの時代には、すべてが成長とともに順調です。AppStoreのトップ3と日々のトラフィックの増加です。

しかし、ご存知のように、不安はいくつかの偽のドミトリエフを引き起こします。 FalseDAUの2つのケースに直面しています。

最初の飛躍。

予想外に、2日間で不審な+30万を獲得しました。2200Kが2500Kに変わりました。

その理由はすぐに判明しました。 iFunnyは登録せずに匿名で使用できます。 このようなユーザーも考慮されます。 APIをクラックした人がこれを利用しました。 計算したランダムな識別子を置き換えて、リクエストを送信しました。

2番目のジャンプ。

ベースをOVHに移動し、ブレーキを停止するとすぐに、DAUがジャンプしました。 UXはあなたにとって冗談ではないと思いました。 アプリケーションはより速く動作し始め、誰もがすぐに使い始めました。 したがって、私たちはさらに熱意を持って、エイプリルフールの企業イベント-記録の準備を始めました。 しかし、残念なことに、これは記録ではなく、アプリケーションをAWSからOVHに移行する数週間の期間でした。 そこでは、データベースと会って、いつまでも幸せに暮らすことになっていた。 この不整合により、MySQLのDAUカウントが正しくないことが明らかになりました。 賢い人はアクセスログでカウントし、何らかの理由で、ユーザーアクションごとに「ユーザーがその日まだログインしていない場合はカウンターに+1する」などの非アトミッククエリを実行します。 その結果、これらのデータベースクエリが長引くほど、並列クエリによりDAUが多くなりました。 ：フェイスパーム：

RedisのDAUの登録とカウントを通常のソート済みセットに転送-これで問題が解決しました。 私たちはこのパターンが好きでしたが、3年でRedisのメトリクスをカウントすることでコードを麺に変えました。 2016年、彼らはfluentd + S3 + Redshiftを介してサーバーおよびクライアントイベントのコレクションを実装しました。 これにより、スパゲッティがコードに保存されました。 これがどのように起こったかについては、別の投稿を書く必要があります。 そして1つでもありません。

レディス・ミスター

時間が経つにつれて、Redisは失敗し始めましたが、以前は問題はありませんでした。 問題のピークは夜でした。 PHPからアクセスできなくなり、すぐにすべてがダウンしました。ほとんどすべてのHTTPリクエストがそこに行かなければならなかったからです。

理解し始めます。Redisプロセスを見て、straceを発見し、そこに「Too many open files」があります。 接続数の上限は1024であり、maxclientsパラメーターの影響を受けないことがわかります。 ulimit -n 60000から始めます-接続の最大数は10240までしか増えず、それ以上は増えません。 彼らは驚くべきことを発見しました。Redis2.4以前では、10,240の接続という厳しい制限がありました。 数日後、彼らはRedisバージョン2.6 RC5をインストールし、永続的な接続をオンにして安reliefのため息をつきました。

モンゴBDSM

チームの成長は2013-14年にのみ開始されます。 QAに加えて、DevOpsチームが編成され、バックエンドとフロントエンドが完成します。 モバイル開発では、iOSとAndroidに3人の開発者がいます。 しかし、初期の段階では、1.5人が残っていました。 したがって、リソースの不足、時間差と平凡な不注意による睡眠不足。 そして、私は多くのことをしなければなりませんでした。 たとえば、APIを数回やり直すか、バックエンドのコードを完全に書き換えて、MongoDBで動作するようにします。 多くの人はそれを通常のデータベースとは考えていませんが。

どこからインスピレーションを引き出すのか、そしてYouPornのあなた。 よく知られた狭い円で、Highscalabilityは、Redisをメインデータウェアハウスとして使用していることを読みました。 もちろん、すべてをRAMに保管するのは怖いです。複雑なアーキテクチャソリューションが必要になります。 しかし、YouPornがすでにRedisに座っている場合、MongoDBに対処することはできませんか？

はい、時々彼女と一緒にいて良かったのですが、より頻繁に鞭でアタットを作り、ギャグを挿入しました。 この小説は今日まで続いていますが、最初の男の地位で、私たちは多くのかんしゃくや学校を経験しました。

すべてを正当化する理由は、箱から出して、もちろん誇大広告だった。 私たちの場合、私たちは怠け者であり、追加のコードを記述したり、データバランシングの問題に対処したりしたくないため、便利でした。 MongoDBに戻ると、インプレース更新、スキーマレスおよび埋め込みドキュメントに魅了されました。 負荷の高いサービスでデータ構造を設計するアプローチについて考えさせられました。 そのため、MySQLからの書き換えと移行を開始しました。 これは2012年半ば頃で、MongoDB 2.0の使用を開始しました。

私たちの将来の試練をすべて予想していた悪い兆候は、すでに始まったばかりです。 書き換えプロセス中にミスが発生しました。 事実、iFunnyに注がれたミームはすべて禁止される可能性があります。これには一定数の苦情が必要です。 MongoDBでしきい値を設定し、運用を開始すると、引き続きMySQLから読み取りました。 そこでは、彼らはほとんどゼロであり、文字通り1つまたは2つの苦情で作業を禁止するのに十分でした。 そして、私たちのトロールを考えると... 4000個の選択されたミームがFeaturedから消えました。 一日ですべてが修復されましたが、私たちの平凡な不注意によるドラマに満ちた状況がありました。

移行

コードを書き直して5か月後、火を消してからの自由時間で、すばらしい移行の日が来ましたが、すぐに失敗しました。MongoDBは負荷に耐えることができませんでした。 多くのインデックスをスローするのを忘れていたからです。 多数のバグが作成されたためです。 生のMongoDB-PHPドライバーは、メモリリークやフォークされたスクリプトの問題で状況を悪化させました。 誰がテストについて何か言いましたか？ 当時はテストがありませんでしたが、時間はありません。新しい機能をすぐに実稼働しています。

その日、私たちのユーザーは、少なくともどこかで笑うことを望んで、9GAGのリソースに突入し、安全に置きました。 少なくとも1つの喜び。

時差も問題を投げかけました。アメリカで最も活動的な時期-私たちは夜を過ごします。 そして、これが私たちが寝なければならない翌朝の様子です。

2週間にわたる骨の折れる作業で、2回目の試行を決定しました。 すべてがスムーズに、ほぼ完璧に行きました。 レプリカとシャードがなければ、私たちは遠くまで行かないだろうという理解がありました。MongoDBを使用すると、簡単に起動できました。

ピーク負荷に達するまでは、すべて順調でした。 基地は夜のユーザーの流入に耐えることができなかったため、私たちは再び横になりました。 同時に、ブレーキの理由は明確ではありませんでした-CPUまたはIO、デバイスは実際には何も話しませんでした。 次の眠れぬ夜の後、 良きサマリア人の助けを借りて、問題の原因があります：MongoDBの標準メモリアロケーターは、負荷の下ではうまく機能しません。 その結果、アロケーターをtcmallocに置き換え、夜を待ち始めました。 出来上がり、負荷が3回低下し、私たちは時々夜に寝始めました。 それから私たちは別の重要なことに気づきました。人々もデータベースを書く。 次のバージョンでは、MongoDB 2.6開発者はデフォルトのディストリビューションにtcmallocを含めるようになりました。

この間ずっと、私たちのサポートは、アプリケーションについて不満を言う手紙を集めました。

どうやら、その後、私たちはユニークな状況にありました。 このような高負荷に直面している人はほとんどいないことが確認されました。 あるいは、言い換えると、このような負荷でこのようなテクノロジーを使用するのは私たちだけであり、原則として、1つのノードで実行できることを認めています。

時間をさかのぼってMongoDBに移行するかどうかを再度決定すると、答えは明確になります。プライマリストレージとして-不要です。 バグの作業は次のようになります：最初に結合を取り除き、仮想シャードでシャーディングを行い、カウンターをどこかに持って非同期に読み取り、スキーマレスでPostgreSQLのjsonbのようなものを使用します。 誰が知っているか、おそらく私たちは再び移行します。 私たちは約束しません。

聴衆

ユーモラスなアプリケーションの視聴者には1つの大きなプラスがあります-すべてを笑うことができます。 たとえば、サーバーがどのように分類されるかについて：

また、「Best on toilet app」というタイトルの投票を手配する人はいません。

多くの場合、アプリケーションがうつ病に対処するのに役立つという事実に感謝の手紙を受け取ります。 ユーモアは癒します：

これはすべて私たちに直接影響します。

iFunnyの技術的な結婚の開始後初めてのことで、ユーザーは開発チームのサルと呼ばれました。 否定しません。 FunCorpロゴをご覧ください。

しかし、別の側面があります。

まず、多くのユーザーがいます。 わずかな間違い-とサポートが過負荷です。

第二に、彼らは自分自身を主張したい。 物事の順序で、コンテンツに対するレイドを手配し、すべてをマイナスします。

ここでAPIが機能していません

APIメソッドが機能しなくなりました。 苦情が降った。 多くの仮説があり、セルラーネットワークによるブロックについても考えました。 しかし、十分な数のユーザーの苦情が集まったとき、パターンを見つけることができました。 これらはジェイルブレイクiPhoneでした。 その後、保護を解除して、独自のフォントやその他の小さなもので独自の調整を実装するのが流行しました。 多くの、特にティーンエイジャーは、面白がって目立つのを助けました。 これらの微調整の1つにアレルギーがありました。サーバーに送信する前に、発信HTTP要求をインターセプトし、ヘッダーをいくつか削除しました。 彼らは、特定の調整に関する問題についてユーザーに警告し始めました、そして私たちはこれに別れました。

私たちはそのようなニュアンスについても考えていませんでしたが、多くの聴衆がその仕事をしています。 今、私たちは、1万または5万人が何人いたかを思い出しません。 アプリケーション全体について-これはごくわずかですが、サポートのために...あなたはすでにそれがどのように見えるかを見てきました。

結論：あなたがクリヴォルキーでなくても、評判は悪くなります。 長い開発経験の中で、FlurryやAWSからAppleやGoogleまで、すべての人にバグやクラッシュに遭遇しました。 これは、ユーザーに対する評判とDAUの両方に打撃を与えました。

不注意

最後に不注意について。 人的要因のため、多くの間違いが発生します。 そして、私たちも例外ではありません。

146％はチュロフだけでなく

IFunnyには投票用のWebアプリがあります。 それで、バックエンドの時間が足りず、フロントエンドがバックエンドのコードを書きたいという欲求のために、投票は非原子的であることが判明しました。 投票数は、コード内のフィールドの通常の増分によって更新されました。ベースの場合、ロックのない典型的な読み取り前書き込みです。 ロシア選挙の最高の伝統には矛盾がありました。 もちろん、ユーザーは私たちをだます。 おそらく彼らは、これは意図的に行われたとさえ考えていました。 しかし、Habréでのみ真実を語ります。

恥の証拠は残っていませんが、雄弁なコメントは残っています。

次の投票では、すべてがすでに正しかったのですが、私たちのスタイルでもう一度数えれば、投票の48％を受け取ったトランプは、プーチンにほぼ2.5倍敗れたと結論付けることができます。

卑劣なずさんな

ユーザーを収集し、ユーザーを収集し、エンゲージし、陽気に陽気に過ごし、それからちょっとしたことを忘れてしまいます。 それらのどれもありません。 2年前に自分の手で観客を撮影しました。

Androidアプリケーションのバッジをサポートしました。 2015年には、サムスンにのみ登場しました。 通知はクールで迷惑ではありませんでした。 しばらくして、バッジが壊れ、誰も気づきませんでした。 数か月後、製品の1つがこれに気付きました。 すべてを修正し、DAUに120Kを追加しました。

QA、製品、および開発者の両方により注意を払う必要があることがわかりました。 そしてあなたに。 はい、はい-あなたに。 さて、あなたはこのロングライドを読みましたが、その間に何かが壊れています。 私たちのようにならないで、チェックしてみてください。

そして、Habréのブログを更新し、新しいストーリーと古いストーリーを共有します。

2013年には、アニメーションの最適化に関するGifへの投稿またはGifへの投稿は1件しかありませんでした 。 長年にわたって、AWS、NoSQL、iOS、Android、テープ内の数学、ビッグデータ、コンテンツの事前調整、スパムなど、おもしろいことをたくさん話しました。 失敗すらしない場合もありますが、良い決断を下し、それぞれにミームが山ほどあります。 したがって、楽しいことが起こるため、人生のユーモアが増えます:)