軽かるく検索けんさくするとS3のレイテンシは1桁けたミリ秒びょう、帯域たいいきはクライアント側がわのネットワークがボトルネックになるまで(つまり100Gbpsレベル)出でるようですね。しかも99.999999999%(11ナイン)の耐久たいきゅう性せいという数字すうじは生半可なまはんかな努力どりょくで出だせる数字すうじではありません。

なぜそんな高速こうそくなストレージがこんなに安やすいのかというのは一言ひとことでは「経済けいざいの力ちから」となりますがもう少すこし噛かみくといくつかの要素ようそがあります。

S3はまき餌えさかも知しれない

クラウドビジネス各社かくしゃではオンプレミスやコロケーションで顧客こきゃく自身じしんが契約けいやくしている物理ぶつりハードウェアからサービスそのままで自社じしゃのクラウド上じょうに引ひっ越こして貰もらうこと、通称つうしょうリフトアンドシフトが基本きほん戦略せんりゃくの一ひとつです。その中なかでデータ置おき場ばを顧客こきゃくが自社じしゃ管理かんりしているNASなどからS3に引ひっ越こしてもらうのは重要じゅうようなマイルストーンです。S3に置おいて貰もらってそこから煮にるなり焼やくなりしてもらうのはクラウドを使つかい込こんでもらうために重要じゅうような起点きてんとなりますのでAWSはそのアップロードの敷居しきいを下さげるためにSnowballなどのサービスを整備せいびしています。またS3にアップロードしたペタバイトクラスのデータを外そとに改あらためて持もち出だすのはとても大変たいへんなので、AWSにロックインさせる事ことを目的もくてきとしてS3は原価げんか以下いかの価格かかくで提供ていきょうしてもサービス全体ぜんたいでは投資とうしが回収かいしゅうできるという目論見もくろみでいわゆる逆ぎゃくザヤをやっているのではないかという説せつもあります（実際じっさいの所ところどうなっているかは知しりません）。とにかくそれぐらいやってもおかしくない戦場せんじょうがクラウドのオブジェクトストレージです。

帯域たいいきは金かねで買かえる

S3を運用うんようする側がわが一体いったい何なん台だいのコンピュータを使つかってサービスを回まわしているかはまるでわかりません。ですがクラウド事業じぎょう者しゃの持もつデータセンター内ないデータ帯域たいいきは市販しはん品ひんとは別べつのライフサイクルで強化きょうかされ続つづけており、EC2で借かりれるマシンの中なかには100Gbpsのネットワーク帯域たいいきが出でる物ものもあります。そしてハードディスクなどのストレージデバイスはクラウド事業じぎょう者しゃは途轍とてつもない規模きぼで買かうのでいわゆる電気でんき屋やで一般人いっぱんじんが買かう価格かかくと比くらべると圧倒的あっとうてきに安やすくなると言いわれています。ですので「とにかく大量たいりょうのデータを保存ほぞんしたいから大量たいりょうのマシンを調達ちょうたつして横よこに並ならべて負荷ふか分散ぶんさんしてするぞ！」と覚悟かくごさえ決きめればハードウェア的てきには25ドル/TB/月つきは実現じつげん可能かのうな範囲はんいにあると感かんじます。もちろんソフトウェアや運用うんようのコストが掛かかるのでゼロからクラウド事業じぎょうを初そめた人ひとがお金かねだけでどうにか解決かいけつできるとは思おもいません。何なににせよ、大量たいりょう調達ちょうたつによる仕入しいれ原価げんかの削減さくげんは重要じゅうような要素ようそです。そしてサービスのインタフェースとしてはオブジェクトストレージなのでサーバ台数だいすうを増加ぞうかさせることによる帯域たいいき幅はばの拡大かくだいは比較的ひかくてき自然しぜんに行おこなうことができます、いわゆるシャーディングですね。HDDはヘッドシークに10ms程ほどの時間じかんが掛かかってしまうのでそこが支配しはい項こうにならざるを得えません、ですので可能かのうな限かぎり内部ないぶでは並列へいれつ化かして帯域たいいきを稼かせいでいます。

レイテンシは知恵ちえでしか買かえない

S3は公開こうかい情報じょうほうによると複数ふくすうのAZ（例たとえば同おなじ地域ちいきの別べつの建物たてものなど）に常つねに複製ふくせいし終おわってから初はじめてクライアントに完了かんりょうと返事へんじをする仕組しくみでその完了かんりょうレイテンシは10ms前後ぜんこうに有あるようです。S3 Express One Zoneというストレージクラスを明示めいじ的てきに選えらぶことで一時いちじ的てきな耐久たいきゅう性せいを少すこし犠牲ぎせいにしてレイテンシを1桁けたミリ秒びょうへと短縮たんしゅくすることができると書かいてあるので、その辺あたりがアルゴリズム的てきな上限じょうげんに引ひっかかる境界きょうかいなのだと見受みうけられます。つまり顧客こきゃくから受うけ取とったデータを複数ふくすうのAZに複製ふくせいし終おわるのを待まつかどうかで数すうmsの遅延ちえんが有あるか無ないかが変かわってくるので最初さいしょに書かき込こみ依頼いらいを受うけたサーバはローカルに書かくかすぐ隣となりのマシンにも送おくるか等とうをして自身じしんが即そくクラッシュしてもデータが永続えいぞく化かされた状況じょうきょうを作つくり出だす事ことで高たかい耐久たいきゅう性せいを実現じつげんしていると考かんがえられます。

データを複製ふくせいすると言いってもナイーブな方法ほうほうでは故障こしょうに弱よわいのでちゃんとアルゴリズム的てきに強つよく検証けんしょうしたものを使用しようする必要ひつようがあり、形式けいしき手法しゅほうを用もちいて確認かくにんを行おこなったという話はなしなどは探さがすといくらか出でてきます。アルゴリズムやサービスのバリエーションなどの側面そくめんでもレイテンシを縮ちぢめる工夫くふうを凝こらしているようです。

僕ぼくは以下いかのブログを流ながし読よみしかしていませんが、実態じったいは絶たえ間まないエンジニアリングの努力どりょくの果はてにできているサービスであることをしみじみと感かんじました。

https://highscalability.com/behind-aws-s3s-massive-scale/