AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAmazon Web Services Japan
![AWS上で使えるストレージ十番勝負](https://cdn-ak-scissors.b.st-hatena.com/image/square/0db76ae81504d5812bd0040e090263be4aea3e9c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Faws20130507-public-130508193232-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
サーバとストレージの性能向上に伴い、それまで複数のサーバで処理していたものを1台の高性能なサーバにまとめる「サーバ統合」は、数年前から大きなトレンドの1つになっている。サーバ統合によりサーバの利用率が向上し、また監視すべきポイントが1カ所になるため運用コストの削減になり、管理すべき対象も減るためにセキュリティの向上にもつながるためだ。
Fibre Channelのストレージエリアネットワーク(SAN)と同等の機能をイーサネット上で実現するFCoE(Fibre Channel over Ethernet)。FCoEでは、10ギガビットイーサネット(10GbE)のデータリンク層に相当する部分をDCB(Data Center Bridge)という技術で拡張し、パケットロスなどをほとんどなくすなど信頼性や性能を高め、その上にFibre Channelのプロトコルをのせています。 FCoEの登場によって、これまで物理的に分かれていたSANとLANの2種類のネットワークは、イーサネットで統一されようとしています。 しかしイーサネットでブロックデバイスとしてのストレージにアクセスするならば、iSCSIを利用してもいいはず。iSCSIとはSCSIプロトコルをIPネットワーク上で利用する技術。10GbEなら当然iSCSIも高速に動作するは
弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。 Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。 @IT Special PR:Fusion-ioのクールな技術を使いこなせ! 今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で
はじめに グリー株式会社でエンジニアをしておりますkgwsと申します。 今回は、前回に引き続き分散ストレージ(nanofs)のHTTPメソッド毎の処理を紹介させていただければと思います。 nanofsは5つのHTTPメソッド(GET、PUT、DELETE、HEAD、MKCOL)をサポートしております。今回は主なGET、PUT、DELETEの3つについてご説明させていただきます。 まずは構成のおさらい nanofsは、主に3つのプロセスで構成されております。 nanofsd(dispatcher) アプリケーションサーバからリクエストを受け取り実際に保存されているnanofsnに振り分ける 5つのHTTPメソッドをサポートしている(GET、PUT、DELETE、HEAD、MKCOL) データベース(KVS)に保存したデータの情報を送る queueに処理の指示を送る nanofsw(worke
2010年9月にはてなの最高技術責任者(CTO)に就任した田中慎司です。はてなの技術全般を見ていく仕事をしています。現在の筆者が注目する技術の一つがクラウドで、はてなのサービスでも利用を始めています。クラウドの技術というと、アプリケーションの実行環境が取り上げられがちです。筆者も2010年3月にセミナーで講演したり、クラウドについてのエントリーを書いたりしました。今回は、クラウドの利用で見逃せないもう一つの部分、クラウドのストレージサービスを、クラウドの利用を検討するエンジニア向けに解説します。 ■ クラウドのストレージサービスとは はてなのようなWebサービスを実現するには、ざっくりいって2種類の環境を用意する必要があります。一つは、サービスを動かすためのアプリケーションを実行するサーバ環境で、もう一つがユーザからアップロードされる多数のコンテンツを保存するストレージ環境です。Micro
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と3サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
仕事で画像キャッシュサーバーを構築した時のメモ。大規模事例の設定例が検索してもあまり見つからなかったので同じような境遇の誰かの参考になれば。 ピーク時のトラフィックは数Gbps 画像総容量は数十TB バックエンドのstorageが複数種類 規模とアクセス量とアクセスされる画像の種類が多いので、squidでdisk cacheを使用するとCOSS等を使用してもdiskIOで詰まる為、全てon memory cache。cache容量を確保する為に必然的にcacheサーバーの台数も数十台。 1. squidをsibling構成で並列に並べる cache_peer 10.0.1.1 sibling 80 3130 no-query no-digest proxy-only cache_peer 10.0.1.2 sibling 80 3130 no-query no-digest proxy-o
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
リレーショナルデータベースを利用する際には、高い性能を引き出すために物理設計をし、スキーマを工夫し、パラメータのチューニングを行うことがつねに行われてきました。 性能のボトルネックはたいがいHDDにあり、いかにそのボトルネックを回避するかがチューニングのポイントですが、最近では性能向上のための武器として、HDDよりもずっとアクセス性能の高いSSDが注目されています。SSDはHDDと置き換えるだけで、アプリケーションにまったく手を加えずに性能向上を可能にする手段として非常に魅力的です。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか? オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました(参考「日本オラクルと富士通 フラッシュ技術活用によるデータベース高速化を共同検証」)。 ホワイトペーパーでは、HDDの代わり
A Place to discuss Oracle VM, Linux and Other Great Software.サーバ仮想化環境では「リソースプール」という概念を実現するために共有ストレージ構成が多く採用されます。しかし、そもそも現在のCPU性能とDISK I/O性能を鑑みれば、そもそもDISK I/O性能はCPU性能の進化に追いついておらず、共有ストレージ構成とすれば追い打ちをかけるようにそこがボトルネックとなります。多くの環境ではサーバ仮想化環境では「共有ストレージ型前提。しかしこれまでの何倍ものI/O性能が必要」という要件に対応するため、ミドル〜ハイエンドのストレージ装置を採用するという選択を行っています。その結果初期導入費用が高価なのはもちろんですが、そのあとも莫大な保守費を支払うことになります。そして拡張できるものの、拡張するためのパーツがまた高価、というスパイラルに陥
多数のユーザーの行動記録からアテンション情報(注目されているデータが何か)をデータマイニングしたいというのは、大量のデータを扱っているウェブサイトにおいては自然と出てくる要求です。そこで、先月末にサービスを終了したサービス「パストラック」において使用していた、アクセスログから注目度(人気度)の高いウェブページや人名等のキーワードを抽出するためのアルゴリズムを紹介しておきたいと思います。 たとえばはてなブックマークのような、ユーザーの能動的な行為(「ブックマークする」という作業)から注目情報を抽出するのは決して難しいことではありません。それは、直近の一定期間内のブックマーク数=注目度、という前提が上手に機能するからです。現に、はてなブックマークの人気エントリーは、最近24時間程度の期間内にブックマークしたユーザー数の多い URL を降順で並べているように見受けられます。 しかし、アクセスログ
2009/05/12 既存データベースサーバのハードディスクをSSDに置き換えた場合、どの程度パフォーマンスが向上するのか? この問いへの回答の1つとなり得るベンチマークテストを、“MrBenchmark”を名乗るサン・マイクロシステムズのチーフ・エンジニアのBenoit Chaffanjon氏が5月11日付けのブログで公開している。 ベンチマークは2種類。1つはオンメモリで処理が完了するもの、もう1つはキャッシュメモリに乗り切らずにドライブ(HDD/SSD)へのアクセスが発生するもの。テストに用いたサーバのコンフィギュレーションは以下の通り。 Solaris 10 Update 6 Oracle 10.2.0.2 Java 1.7 build 38 SLAMD 1.8.2、iGenOLTP Sun Blade X6270(Xeon X5560@2.8GHz×2、DDR3 32GB) In
前回の「ストレージをデータ保護から理解する」では、ストレージの内部アーキテクチャ、データ保護、可用性、信頼性について解説した。今回は、ストレージの性能の考え方を解説する。 ハードディスクドライブの仕組みと性能の考え方 まず、ストレージの性能を理解するため、多くのストレージで記録媒体として採用されているハードディスクドライブ(HDD)の仕組みと性能の考え方について解説する。HDDは磁性体を塗布したディスク(プラッタ)を回転させ、移動するアームの先端に取り付けた磁気ヘッドによりデータを記録する(または読み取る)。プラッタは同心円状のトラックに区切られ、各トラックを回転方向に分割したセクタで構成される。なお、最近のHDDはプラッタの内周から外周にかけてトラックをいくつかのゾーンに分け、セクタ数を段階的に多く配置していくZBR(Zoned Bit Recording)方式を採用している。そのため、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く