Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。2009においてTwitterのアーキテクチャ、とりわけ過去一年にわたって行ってきたウェブサイトの最適化について語った。Twitterで使われているツールの多くはオープンソースである。そのスタックは、フロントサイドにRails、中間のビジネス層にC、Scala、Java、データストアとしてMySQLを利用してつくられている。すべてがRAM上に保持されており、データベースは単なるバックアップである。Railsのフロントエンドはレンダリング、複合キャッシュ、DBクエリ、同期的挿入を扱う。このフロントエンドは、MySQLクライアント、Memcachedクライアント、JSONクライアントなどの、多くはCで書かれたいくつかのクライアントサービスを主につなぐ役目も果たしている。ミドルウェアとしては、Memcached、ページキャッシュとしてのVarnish、Scalaで書かれたMQであるKestrelを利用している。Scalaで書かれた、多数のつぶやき(tweets)をトラッキングしようと考えているクライアントが使うCometサーバを利用するための作業が進行中である。Twitterは“メッセージングプラットフォームではなくコンテンツマネジメントプラットフォーム”として始まっており、そのため、まとめて読むことを基礎にした初期モデルから、すべてのユーザが最新のつぶやきで常に更新される必要がある現在のメッセージングモデルに変更するために、多くの最適化が必要とされた。変更は、キャッシュ、MQ、Memcachedクライアントという3つの領域で行われた。キャッシュ各つぶやきは平均126ユーザにトラッキングされている。そのため、明らかにキャッシングが必要である。当初の設定では、APIだけがユーザからつぶやきが届くたびに無効化されるページキャッシュを持ち、残りのアプリケーションはキャッシュレスであった。Cache)をつくることだった。このキャッシュは99%のヒット率を持っている。Cache)を加えることだった。Kallen氏のRailsプラグインを利用している。Nick氏はTwitterのシステムアーキテクトである。Cache)を導入することであった。ここで、つぶやきの直列化バージョンとは、APIクライアントを通してアクセスされ、JSON、XML、あるいはAtomでパッケージングされているものである。このキャッシュも同じく95%のヒット率を持つ。断片キャッシュは「直接ベクターを消費し、もし直列化された断片がその時点でキャッシュされていたら、誰かが見ようとして要求したつぶやきの実際の列データをロードしない。やって、データベースアクセスを避けて、多くの時間を節約する」とEvan氏は述べた。1つの変更は、ページキャッシュとは分離されたキャッシュプールをつくることだった。scheme)を用いている。その理由は、クライアントはHTTPのif-modified-sinceを送ることができ、リクエストの中で好きなときにタイムスタンプを押すことができます。私たちはその列をスライスして、クライアントが見たいつぶやきだけをクライアントに提供する必要があります。クライアントが利用した可能性のあるキーをすべてトラッキングしたくはないのです。この世代型手法には大きな問題がありました。すべての無効なキーを削除することができなかったからです。つぶやきの数にしたがってユーザが受け取る各ページが追加されるたびに、キャッシュ内の有効なデータを押し出してしまいます。その結果、私たちのキャッシュは5時間の実効時間しか持つことができませんでした。これらのページキャッシュのすべてがずっと流れ続けているからです。ページキャッシュがプールに移動されることで、キャッシュミスは50%削減された。以下の図が現在Twitterによって使われているキャッシュ手法の図である。Twitterのトラフィックの80%がAPI経由であるため、そこには2つのレベルのキャッシュが追加されている。それぞれのキャッシュは、その前の層から来るリクエストの最大95%を提供する。全体のキャッシュの変更は、計20から30の最適化によって達成され、それによってもたらされたものは10倍のキャパシティの改善でした。できたかもしれませんが、私たちはその時点で別のボトルネックにぶち当たったのです...。IDが届くたびごとにキャッシュを壊すのではなく、修復してオンラインにすることです。各ユーザには平均して126のフォロワーがいるので、各つぶやきに対するキューには126のメッセージが存在するということになる。なくても、トラフィックがピークに達する時というのがある。それはオバマ大統領の就任式のときなどで、そのときには、毎秒数百のつぶやき、言い換えるとキューの中に数万のメッセージがあるという状態になり、そのトラフィック量はその当時の通常のトラフィックの3倍の量であった。MQはピークを見つけて、それを時間をかけて分散するようにし、その結果として、さらなる多くのハードウェアの追加をしなくてよいようにする。TwitterのMQはシンプルである。Memcachedプロトコルをベースとしており、ジョブの順序づけはなく、サーバ間の共有状態もなく、すべてはRAMに保持され、トランザクション処理である。MQの最初の実装はRubyで書かれたStarlingを利用していたが、特に世代型ではないRubyのガベージコレクションのためにうまくスケールしなかった。その結果、ガベージコレクタがその作業を終えるまでの間キュー処理全体がある時点で止まってしまうことが理由でMQがクラッシュした。そこで、MQをより成熟したJVMのガベージコレクションを利用するScalaに移植することが決定された。現在のMQはたった1200行のコードからなり、3つのサーバ上で稼動している。MemcachedクライアントMemcachedクライアントの最適化は、クラスターのロードの最適化を目的としたものだ。現在のクライアントが使っているものは、libmemcachedであり、Twitterがその最も重要なユーザであり、コードベースへの貢献者となっている。そのlibmemcachedをもとにして、一年以上かけて断片キャッシュの最適化を行うことにより、1秒間に処理するページリクエストが50倍に増加した。リクエストに局所性がないため、リクエストを処理するもっとも高速な方法は、データを必要なときに各サーバで再処理することではなく、データを事前処理しネットワークRAM上にストアすることである。この手法はWeb2.0のサイトの多くで利用されているもので、それらのサイトはほぼ完全にメモリ上で稼動している。次のステップは、Evan氏によれば、「1年間読み取りのスケーリングを行って、その後、書き込みのスケーリングを行う。それから、複数コロケーションの問題に取り組む」とのことだ。QConでのプレゼンテーションのスライドがEvan氏のサイトで公開されている。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。