S3のZipファイルをRangeでバイナリアクセスして料金を節約 - HDE BLOG
あけおめころよろメリクリ!! 尾藤 a.k.a. BTOです。 今年も残すところ、あと357日となりましたが、みなさんいかがおすごしでしょうか。 今年の目標は、純白のメルセデス、プール付きのマンション、最高の女とベッドでドン・ペリニヨンの3つです。 さて、今回はS3上に置いたZipファイルをHTTPのRangeパラメータでバイナリアクセスして、料金を節約した話を書きます。 検索インデックスのデータ量が増大 メールアーカイバでは、検索インデックスを mongodb に格納していますが、データ量が増えるにしたがって性能的な問題が出てきました。なにしろ月間1億6000万通のメールを処理するので、検索インデックスのデータ量も大変なことになります。 amazon EBS 1TB制限 当時のEBSでは、最大で1TBのボリュームしか作れませんでした。 検索インデックスのデータ量の増え方は不規則なので、ど
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
Railsアプリの設計をMVCごとに見直しリファクタリングして連載総まとめ
連載目次 前回の『「設定より規約」のRailsで必要なセッティングの基礎知識と国際化／多言語対応』まで、サンプルプロジェクトの「book_library」を題材にRailsのさまざまな機能を紹介してきましたが、今回はRailsアプリケーション開発を紹介してきた本連載のおさらいとして、サンプルプロジェクトをMVCごとにリファクタリングしたいと思います。 「book_library」は社内の書籍を管理するためのアプリケーションで、これまでRailsの各機能を紹介するため場当たり的にさまざまな機能を盛り込んできましたが、もっとシンプルに作ってみましょう。 コントローラーの見直し まずは、連載第7回の「Rails開発を面白くするアクションコントローラーの5大機能とルーティングの基本」で解説したMVCの「C」、コントローラーです。コントローラーの見直しは名前空間やネストによる外部構造と、アクションの
閏秒を迎えるにあたってLinuxでは何を対策すべきか？ | Act as Professional
2016/12/27 更新Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。 元旦に実施される うるう秒の対策 まとめ2016/07/08 更新2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新)下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの２バージョンはパ
成長する開発チームでの施策 - ワザノバ | wazanova
https://www.kickstarter.com/backing-and-hacking/engineering-year-in-review-2014 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 Kickstarterの開発チームは昨年14名から20名に。成長しているサービスでチーム規模が大きくなる中、どのようにエンジニアをまとめ、モチベーションをあげ、優秀な人材を採用できるようアピールしているのか？開発チームの１年間の振り返りのブログエントリーからその施策の一部が垣間見えます。 ミートアップ、Functional Swiftのカンファレンスを主催。 各Engineering leadをアサインし、クロスファンクションのチーム構成とし、VP of Engineeringを採用。 エンジニア
Docker と SO_REUSEPORT を組み合わせてコンテナのHot Deployにチャレンジ - blog.nomadscafe.jp
「Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1」のその2です。 結論から言うと、「単体ではリクエストの取りこぼしが若干あるけど、Reverse Proxyを工夫すればコンテナのHot Deployを実現できるかも」という感じです。 Rhebok の SO_REUSEPORT 対応 前回は簡単に検証するためにmemcachedを使いましたが、今回はアプリケーションサーバが対象ということで、 unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。version 0.2.3〜です。 rhebok | RubyGems.org | your community gem host 起動時に ReusePort オプションを追加します。 $ bundle exec rackup -Ilib -s Rhebok
Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1 - blog.nomadscafe.jp
SO_REUSEPORTはLinux Kernel 3.9からサポートされている機能で、複数のプロセス/Listenerから同じTCPポートをbind可能にして、Kernelが それぞれのプロセスに接続を分散してくれるという機能です。preforkなサーバはlistenしてからworkerをforkし、それぞれでacceptを行うという手順を踏みますが、SO_REUSEPORTを使えばその手順を踏まなくても複数プロセスから同じポートをListenして処理の並列性をあげたり、hot-depolyが実現できます。 Docker のHost networking機能とSO_REUSEPORTを使って、複数のコンテナから同じポートをbindできれば、コンテナのhot-deployができるんじゃないかと思ったので、試してみました。 SO_REUSEPORTについては以下のblogが参考になります。
いかにしてウィキペディアを編集する際の速度を二倍にしたか - Qiita
How we made editing Wikipedia twice as fastという記事を翻訳しました。ライセンスはCreative Commons Attribution 3.0 unported licenseです。画像も、注意点がない限り、同じか、画像のリンク先のライセンスを確認してください。間違いだらけだろうから、何かあったら、ぜひコメントください。 "ウィキ"とは速いという意味だった... ウィキを開発したWard Cunninghamは、素早く簡単に編集できるウェブページを作りたかった。Cunninghamは自身のソフトウェアにハワイ語の「速い」という言葉をつけた。それがウィキメディア財団がウィキペディアの編集のソフトが二倍になったことを広く知らせる理由だ。過去6ヶ月間、PHPのコードを使ったウィキペディアの裏方であるメディアウィキの速度をあげる新しい技術に取り組んでい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BLOGOS サービス終了のお知らせ