GPUを用いたSSLリバースプロキシの実装について - ゆううきブログ
近年，汎用計算の高速化のためのアクセラレータとして注目されているGPUを，ネットワーク処理に適用する一環として，サーバサイドのSSL処理に注目した論文を読んだので，内容を軽く紹介します． SSLShader - GPU-accelerated SSL Proxy SSLShader SSLShader: Cheap SSL acceleration with commodity processors Proceedings of the 8th USENIX conference on Networked systems design and implementation 2011 なお，評価に使われた実装の一部のソースコードが公開されています． http://shader.kaist.edu/sslshader/libgpucrypto/ 紹介 背景 SSL(Secure Socket
Chef Casual Talks Vol.1で「ChefとCapistranoの境界線」について問題提起してきた #eytokyo - めもおきば
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja 大きく分けて二つの話をしました。 Chefを導入する時の「考え方」 Chefのような構成管理ツールは万能でやり方もたくさんある(TMTOWTDI)ので、最初にどういうポリシーで組み立てるかが重要になります。今回「本気で使う」にあたり、以下のようなポリシーを設定しました。 原則サーバ上で作業せず、Chefで環境設定を実装する 公開されたcookbooksを再利用する opscode-cookbooksにあればそれを探す communityやgithubにあるcookbookを使う あきらめの心を持つ 必要ならばopscode-cookbook�sなど既存のcookbookをforkして手を入れる 半日調べて難しそうなことはあきらめる(自前Chef recip
Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) - 元RX-7乗りの適当な日々
昨日エントリ「Amazon EBS の性能ベンチマーク その1 (Standard編)」の続きです。 昨日のエントリで、次はEBSボリュームのサイズを20GBではなく、もっと大きなものにしてみたら、どうなるのだろう？と疑問となった部分があるので、そこのベンチマーク結果となります。 ベンチマークの条件の詳細等は、以下の昨日のエントリからご確認くださいませ。 Amazon EBS の性能ベンチマーク その1 (Standard編) 5. 200GBのEBSボリュームを使ったベンチマーク おさらい的にベンチマークを取得した環境は以下です。 東京リージョン(ap-northeast)で実施。 c1.xlarge (High-CPU Extra Large Instance) のインスタンスを利用。 http://aws.amazon.com/jp/ec2/instance-types/ によると「
AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで
AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで：AWS OpsWorksアプリケーション運用の勘所（1）（1/5 ページ） はじめに 2013年2月にリリースされたAWS OpsWorks。筆者が試しにいじっているうちに、どう使うと便利なのか、気を付けないと逆に運用が大変になるポイントなどが見えて来ました。 本連載では、何回かに分けてAWS OpsWorksの便利な点、不便な点をおさらいしながら使い勝手を紹介して行きたいと思います。題材として、「EC-CUBE」というAWS OpsWorksに最適化されていないオープンソースのパッケージを使ってみました。 AWS OpsWorksは、Amazon Web Servicesが提供するChefをベースにしたサービスです。Chefのレシピを使ってシステムの構成などを一元的に設定できます。また、アプリケーションのデプロ
サーバ用途でコンシューマ SSD へ調子に乗って書き込みすぎると壊れるという話 - mura日記 (halfrack)
Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。 石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSD にやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime 数百日における平均値であることに注意。 [root@touge ~]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
昔の SSD はタフだった - mura日記 (halfrack)
d:id:halfrack:20130417:1366193468 を見た同僚が教えてくれた X25-M G2 のホストについて、古い SSD はマージンたっぷりだったという話。 このホストは DB サーバだが、メッセージングサービス的なものに使われているので、更新ヘビーで辛い DB になる。 [root@nantokagoe smartmontools-6.1]# uptime 19:29:02 up 1028 days, 2:49, 2 users, load average: 0.00, 0.05, 0.04 [root@nantokagoe smartmontools-6.1]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
今日からすぐに使えるデプロイ・システム管理ツール Fabric 入門 - 科学と非科学の迷宮
Fabric は、Python 製のデプロイ・システム管理ツールです。 最近、構築や運用を自動化するための様々なツールが出てきています。 構成管理ツールの Puppet や Chef が有名ですが、使うまでに覚えることが多いのが欠点です。 しかし、Fabric は非常にシンプルなツールで、今からすぐに使うことができます。 Fabric はデプロイ・システム管理ツールで、類似のツールとして Ruby 製の Capistrano があります。 Fabric の最大の特長は、シェルスクリプトを書き慣れた人がいきなり利用できるところです。 シェルスクリプトとしてまとめていたコマンドをそのまま run() メソッドや sudo() メソッドで囲むだけで、使うことができます。 シェルスクリプトを使っていていると、いくつもの問題に遭遇します。 名前空間の管理 変数の扱い 複雑なデータ構造がない(せいぜい
子供チャレンジのDVDがチャレンジングすぎる件 - やねうらおブログ(移転しました)
息子が四歳になり、子供チャレンジの教材でひらがなを覚えた。子供チャレンジの教材にはDVDがついてきており、これが秀逸で、DVDメニューで正しい選択肢を選んでいくと物語が進んでいくようになっている。もちろんその選択肢はひらがなで書いてある その今月のDVDなのだが、「どうぶつえんにいこう！」というのがあって動物園に遊びにいくストーリーになっている。コメディアンらしき二人が家を出かけるところからなのだが、最初の選択肢が 1) くつをはく 2) くつをあらう 3) くつをしまう である。 息子は迷わず2)を選択。 「くつをあらう」 そうするとそのコメディアンらしき人がおもむろに A「さ〜、靴をまず洗うか〜」 とか言ってゴシゴシ洗い出すのである。まったく意味不明である。頭おかしい。 そして、洗いたてでびしょびしょの靴で家を出発。 A「靴がびしょびしょで歩きにくいよ〜」 B「ねぇねぇ、どうして靴洗っ
ZFS優しすぎ涙がでた。 - 春木屋
前口上 試しにZFSを使ってみて（VMware Playerで気軽に試せるようになったとは、なんと便利な世の中か）本当に驚いた。 ディスク繋いでzpoolコマンド一発ですぐ使える。パーティションに頭を悩ませる必要もない。RAIDだって楽勝。ディレクトリごとに圧縮することもできるし、気が変わったら、いつでも止めることもできる。スナップショットも早い。 実は、何年か前にZFSについて調べたときはまだまだバギーな印象だったのと、ZFSを使えるようなパワフルマシンがなく保留にしてたんだけど、すごく損した気分。 いままで幾たび、fdiskやnewfs失敗してひどい目にあったことか。電子の海に消えたデータを思う。 そしてRAID。ソフトRAIDで言えばlvmも有名だが、俺にはもうコマンドが複雑すぎて覚えられない（lv...が論理ボリュームを、pv...が物理ボリュームを扱うんだって？）。 これはすごく
情報は看板に集まるでござる - Chikirinの日記
かれこれ 2週間ほど梅原大吾さん関連のエントリを書いてるんですが、その間いろんな人から情報をいただきました。 たとえば「Ted にゲームに関するスピーチがありますよ！」とか、 「梅原さんは過去にこんなこと言ってました。ブログの話と矛盾しませんか？」 「ウメ昇龍というのがあるんですよ、知ってます？」などなど。 他にも「僕もゲーセンでいろいろ学びました！」とか。 コレも笑えましたね。ありがちすぎ → 日本最大の格ゲー大会 “闘劇2012”がスゴイことに！ 極めつけは「ちきりんさんのブログ読んで、NYUで行われた梅原さんの講演に行ってきました。200人ほどの会場は立ち見がでる大人気。対談後も梅原さんとのツーショット写真を求めるファンが列をなしてて、そのヒーロー性にびっくりしました」というレポートメールまで。 情報を送ってくださった皆様には心から感謝しています。 ★★★ さて、こういうのをビジネス
Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
