はじめに
アカツキでは開発にスクラムの要素を取り入れています。しかし、現状の開発のやり方に漠然とした不安がありました。その不安とは、例えば、もっと効率的になるんじゃないか、もっと良いやり方があるんじゃないか、このやり方はスケールしないのではないか、等といったことです。そこで第三者の目が必要だろうと、ryuzeeさんにアドバイスしていただくことになりました。
続きを読むDeveloppers Summit 2016で「大規模Redisサーバ縮小化の戦い」というテーマで発表してきました。
Redisのdumpファイルを取得して、それらをマージする方法や、Redis内で使用するdb数を増やせば、接続数も増えていく、といった話をしました。 特にAWS上でRedisを運用する場合、ElastiCacheの接続数上限は変更できないことは見落としがちなポイントなので、サーバを何十台もスケールアウトする人たちにとって役に立つノウハウが共有できたのではないでしょうか。
当日はネタスライドを山程仕込んで 会場は大爆笑だったのですが、slideshareではネタスライドは割愛しております。
デブサミのスライドでは、ほとんどの話が縮小についての話だったので、今回はRedisの信頼性について考えてみたいと思います。
続きを読むRailsではコネクションプール数を設定していても、1スレッド辺り1コネクションしか持ちません。
アカツキではRails + Unicorn + Nginx + MySQLの構成をAWSで運用しており、c3.4xlarge
のインスタンス上で1台辺り64のUnicornワーカープロセスが実行される設定になっています。
ソーシャルゲームでは時にたくさんのアプリケーションサーバを並列稼働される必要がでてきます。特に年末年始の時期は平時の2-3倍のトラフィックが予想され、アプリケーションサーバを最大100台で稼働させる必要がありました。
Railsのdatabase.ymlのpool設定は5だったので、単純に考えると最大 100台 * 64プロセス * 5接続 = 32,000個の接続が常時貼られるのでは?MySQLのmax_connections
の設定は大丈夫か?という議論があり、Railsのコネクションプールの実装をきちんと理解すべき!ということで、調査しました。
前回の記事から続いて、今回はElixirで利用する基本的な制御構文について学んでいきます。
多くの関数型プログラム言語では、2要素のtupleによって関連付けられたデータ構造を表現します。 Elixirでは、最初の要素がAtomであるTupleのListのことをKeyword listと呼びます。
iex> list = [{:a, 1}, {:b, 2}]
[a: 1, b: 2]
iex> list == [a: 1, b: 2]
true
iex> list[:a]
1
キーが重複している場合、先頭に格納された値が優先的に読まれます。
続きを読む