Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
1000万ユーザに耐えるサーバを作ってみた
概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく
docker pull を速くするために：layer-parallel から chunk-parallel へ - 薄いブログ
この記事は Recruit Advent Calendar 2021 の15日目の記事です。 TL;DR 従来のレイヤー並列の pull より Range リクエストを用いたチャンク並列の pull によって速度が 2~5倍速くなる可能性がある。 ECR は Public だと region ごとに速度が大きく異るので安定した速度を求める場合は Private にする。 (pull through cache を活用すると良い) 2022/10/9 追記: ECR の Public が適切な Pop から返ってくるようになっていた。 その Benchmark も取得し、結果を追記した。 ap-northeast-1 では6倍近く早くなっていて region による差が小さくなっていた。 背景・動機 コンテナイメージは一つ以上のマニフェスト、そこから得られるコンフィグとレイヤーから構成される
Goとマルチコアスケール実装
マルチコア化の未来予測 半世紀前にSF映画「2001年宇宙の旅」に登場するコンピューターHAL-9000が並列コンピューティングの未来を示しました。マルチコアで構成されたコンピューターの物理コアを取り除いてもすぐにクラッシュせずに性能ダウンして処理が継続するという演出がありました。 当時ですらシングルコアコンピューティングの限界が予想されていて、現状のコンピューティングがマルチコア化しているという未来をしっかり予測できていたことがわかります。 演出はコア数に応じてコンピューティング性能がスケールしていることを表現しています。これはマルチコアスケールするソフトウェア実装の未来を示していたと思います。 シングルコア性能向上の頭打ち 2003年以降あたりはCPUの動作周波数が伸び悩み出したところ。 https://queue.acm.org/detail.cfm?id=2181798 より その
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
PlayFrameworkをただの静的型付けMVCだと思って本番稼動させると死ぬ - サナギわさわさ.json
(3/15 : タイトル修正しました。wは小文字ですね、すみません・・・) PlayFrameworkが流行り始めてから割と経ちますので、そろそろ正式採用しようと考える方も多いのではないかと思います。 強力な静的型付けで守られたPlayは、ミッションクリティカルなシステムや数万行を超える大規模システムの構築に特に向いているような気がします。 また、Servletを使っていないのに加えてMVC構造がベースなので、今までRailsなどで開発をしていた人でもシームレスに移行できると思います。 しかし、忘れてはならないのがPlayのアーキテクチャが全ての処理が非同期で行われることを前提としているという事です。 ここを忘れてPlayをただの強力な静的型付けで守られたMVCフレームワークとだけ考えて開発を進めてしまうと、本番環境で稼動させた時にパフォーマンスが上がらずに困ることになるかもしれません。今
運用してわかった Amazon RDS のパフォーマンスを上げる 3 つのコツ
本番環境で RDS を運用して数ヶ月。いろいろ試して RDS のパフォーマンスを上げるコツがわかってきたのでまとめたいと思います。 ここで取り上げるコツは以下を前提にしています。 データベースは PostgreSQL (Multi-AZ 配置) Read よりも Write が多い 夜間のバッチ処理がピーク 1 レコードは小さいが、一度に書き込むレコード数は多い アプリケーションの特性によっては当てはまらないこともあるでしょうし、他の RDBMS では結果が違ってくると思います。そこを踏まえたうえで参考にしてください。 Availability Zone はどちらかに寄せる RDS の Multi-AZ は耐障害性を上げるために欠かせない機能で、本番環境では Multi-AZ 配置が推奨されています。 Multi-AZ 配置にすると物理的に独立した AZ (Availability Zon
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
Slow Query Logでみるとこ - さよならインターネット
User@Host: kenjiskywalker[kenjiskywalker] @ localhost [] # Query_time: 0.00011111 Lock_time: 0.000099 Rows_sent: 1 Rows_examined: 300000000000000000000000 SET timestamp=999999999999; SELECT girl FROM girls_list WHERE name = 'homuhomu' みたいなスロークエリログがあったとして、 確認すべきところは Query_time = クエリの処理にかかった時間 Lock_time = ロックされた時間 Rows_sent = クエリにヒットしたレコード数 Rows_examined = 探索対象となったレコード数 で、ロックとかクエリにかかった時間は基本だと思うんですけど
Aerospike on Amazon EC2 - Recommendations | Aerospike Documentation
The AWS-related information provided here is given with the performance requirements of Aerospike in a production environment in mind. For development purposes, the Aerospike Community Server will work on any of the instances which have at least 256MB of RAM dedicated to the Aerospike server. Enterprise versions need at least 1GB of RAM. Aerospike provides CloudFormation templates that are already
Linux Tips - HDDベンチマーク手順＋性能測定結果一覧（hdparm,dd,bonnie++）
Linux Tips – HDDベンチマーク手順＋性能測定結果一覧（hdparm,dd,bonnie++） システムのパフォーマンスが思うように上がらない場合、ハードディスクのIO性能がボトルネックになっているケースが多く見られます。 システムの環境構築が完了した後には、ハードディスクのIO性能を必ず測定しておきましょう。ここで紹介するHDDベンチマークを実行して、測定結果の妥当性を評価することによって、ほとんどのケースでディスクIO性能に起因する性能問題を未然に検知することが可能です。 ハードディスクのIO性能を左右する要素システムのパフォーマンスが思うように上がらない場合、ハードディスクのIO性能がボトルネックになっているケースが多く見られます。 以下に主要な項目を挙げるように、ハードディスクのIO性能は様々なシステム構成要素やその設定によって左右されます。システムのインフラ基盤で性能
ファイルディスクリプタをperlで見てみたいときメモ - tweeeetyのぶろぐ的めも
はじめに ディスクリプタがなにか？とか、ファイルハンドルの概念とは？とかっていう話ではないです。 純粋に見てみたいだけのメモですｗ 特にperlが実行されるプロセスで何回もファイルオープンしたら 何回もディスクリプタが作られるところを見たいというメモです fileno(ファイルディスクリプタを得る) 前置きですが、perlでファイルディスクリプタを得たいときの関数 fileno(ファイルハンドル) →http://perl-cgi.net/function/fileno/ 試し最初 ということなので、まずはこんな感じに見てみます perl file_descriptor_test.pl open ( my $fh, '<', './input.txt' ) or die $!; print fileno $fh; close $fh; 結果 # perl perl file_descrip
[SDN]List性能問題
懸案だったMonadic Programming、Functional Reactive Programmingもある程度目処がついてきたこともあり、要件定義で作成されたモデルを実装に落とし込むという流れの中での総合的なScalaプログラミングの方法論をScala Design Noteという切り口で考察していこうと思います。 大昔にJava World誌で「Java Design Note」という連載を書いていましたが、そのScala版をイメージしています。 Scalaを実務に使う場合に注意が必要なのがListの性能問題です。 Scalaでは関数型言語の伝統を踏襲してLispのList由来のListを基本データ構造としています。システムの各種デフォルトもListを使う方向になっていますし、文法を説明する場合にもListを使用するケースが多いと思います。 Listは関数型プログラミングとの
覚えておきたいカーネルパラメータの変更方法 - Qiita
概要 カーネルパラメータを変更する機会があったわけですが、全くといっていいほど今まで気にしたことがなかったのでこれを機にカーネルパラメータ周りや sysctl の使い方を整理してみます。 sysctl 説明 man sysctl より抜粋 sysctl は カーネルのパラメータを実行時に修正するのに用いる。変更できるパラメータは /proc/sys/ 以下にリストされているものである。 Linux における sysctl の機能には procfs が必要である。 sysctl は sysctl データの読み書き両方に使える。 option について option 意味
Log4j 2にも採用されたLMAX Disruptorはなぜ狂ったように速いのか？
LMAXという会社はおそらくFX業者で、筆者はLMAXの開発者の講演を、InfoQの動画で何度か見たことがあった。 彼らは非常に特異な集団で、さしずめ「Javaのスピード狂」という感じだ。 印象的なのは、シングルスレッドで仕事を片付けることを強調している点だ。 「Javaならマルチスレッドで並列処理すれば性能が出ると広く思われているが、我々の仕事においてはシングルスレッドが最速だ」というような主張を何度も見た。 ゴールドマンサックスといいLMAXといい、やはり多額の金が動く会社でガチでJavaをやっている連中はカリカリにチューニングするため、技術的には非常に面白い。 彼らがコアのライブラリをOSS化してくれるというのは、金融業界を否定的な目で見る筆者からすると複雑だが、悔しいことに参考になる。 LMAX DisruptorはJavaのライブラリだ。Producer/Consumerパターン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBやめてみた / DNS water torture attack and countermeasures
Aerospike Real-time Data Platform
Webフレームワークベンチマーク2015
gatlingの使い方 - Qiita
SSSSLIDE
