『画像システムの車窓から』

2年半くらい画像システムを担当していたのですが、3月イッパイで異動することになりましたokzkです。 異動記念ということで、とりとめもなくエンジニアブログを書いてみます。長いです。よろしくお願いいたします。 画像システムのこれまでのストレージ事情最初にアメブロ(以下、単にブログ)のユーザ投稿画像関連でのストレージの歴史をアレコレをまとめてみようと思います。なお、以下swiftと書いたらOpenStack Swiftのことです。流行のプログラミング言語のことではありません。 はるか昔の状況昔は単純にWebDAVを複数台並べ、イッパイになったら更に次の世代のWebDAVを追加する、というような構成で、参照時に画像URLパスに含まれる年月ベースで適切な世代のWebDAVにルーティングしていました。 (参考:画像URLのパスの例) /user_images/20160401/00/shibuya/

[okzk]

id:sue445 S3ですー > "札束で解決" / 他アレコレ回答 -> http://okzk.hatenablog.com/entry/2016/03/25/231716

[kakerukaeru]

涙なしには読めへん

[sue445]

“そんなこんなで新規投稿分は札束で解決できる状況にしたのですが” / Fusion-IOかな。。。-> S3らしい http://b.hatena.ne.jp/okzk/20160324#bookmark-283077766

[efcl]

画像配信、ストレージサービスの設計

[jinjor]

いつか読む。

[teppeis]

ストレージより退職リスクについて考えさせられる

[tmatsuu]

とても良い知見だ。合掌

[huydx]

しゅごい

[luccafort]

学びあるエントリだった。ただところどころよくわからん単語が出てくることがあったんだけどもあれは社内用語的なものなのか、それとも単純にぼくの無知なのか。

[ya--mada]

ちょうど調べようとしていた事案だ。

[kimutansk]

単なるファイル数でサービスを殺せるは確かに昔どこかで聞いたことが・・・ベストプラクティスはいい。ユースケースなりの対応があるわけですね。

[t-cyrill]

どこの会社さんも同じようなことを考えているなーと思いました。面白かった。

[nakag0711]

lsが重たくなるのってさらにファイル名の末尾文字でサブディレクトリに分けて逃げたりするけど、そういうレベルではない？一括コピーはloopデバイス使うとか

[y_uuki]

おもしろい

[coyu8]

退職エントリかとおもったら、異動エントリだった。

[ono_matope]

Swiftはオブジェクトが増えると書き込みパフォーマンスが下がる話、GREEでも言ってたけどやっぱり厳しいんだな。/ Log structured files 自前実装は気合入ってる。

[easy-breezy]

取り消し線の多さに底無しの苦労を垣間見た

[d-kuma]

単なるファイル数だけでもサービスを殺せる＞昔やってたサービスで同じのに当たったっけ。inodeの上限超えたファイル数になるやつ。。

[Jxck]

知見

[murasaki11]

知見だ

[love0hate]

イイハナシダナー

[nilab]

画像システムの車窓から｜サイバーエージェント 公式エンジニアブログ

[m0t0m0t0]

「単なるファイル数だけでもサービスを殺せる」わかります。

[auient]

この知見刺さる。尊さを感じる

[t_f_m]

"えー、そんなわけでー、皆様におかれましてはー、単なるファイル数だけでもサービスを殺せるという事実を覚えていただけるとウレシイですー。 "

[hiroyukixhp]

# 美味しいビールを飲みに行きたいです。

[kyohei_hamada]

分かりやすくて良かった

[fumikony]

異動多くない？

[indication]

サツタバはとても良い響き

[ngsw]

理解が乏しく恐縮なのですがこれは、CSSスプライトみたいなことをアーカイブファイルとインデックスファイルで実現した、という理解でよろしいのでしょうか。

[hirafoo]

打ち消し線が見づらい

[paul_oguri]

“一年後にヤメた”

[heignamerican]

とてもよい記事だった。　数の暴力vs札束の暴力