アスタミューゼ株式会社にジョインしています - 元RX-7乗りの適当な日々
(株)サイバーエージェントの退職報告後、多くの方にお声がけいただき本当にありがとうございました。 さて、私事にはなりますが、9/28付でアスタミューゼ(株)に入社しました。 当面は、Webエンジニアリングの現場で、インフラが中心にはなりますが、何でも屋的な感じで仕事をするつもりです。 何をやってる会社？って思う方が多いとは思いますが、事業内容については、コーポレートサイトやプラットフォームサービスとなる"astamuse"を是非ご覧いただければと思います。簡単に言うと無形資産・知財を扱っているわけですが、私も一技術者として、テクノロジーがもっとイノベーションに結びつきやすくなるような世の中を創れたらと思うし、少しでもその役に立てれば良いなと考えています。 少し話は変わりますが、入社直前の日に義母が58歳という若さで病に倒れ他界しました。細かい話は書きませんが、本当に人生いつ何が起こるかわか
大量の接続がやってきた!ヤァ!ヤァ!ヤァ! - 元RX-7乗りの適当な日々
※ 以下、フィクションです。 はじめに： こんなサーバ(↓dstat) (裏バッチによりiowaitとLAが高いのは一時的な仕様とする) 気付けばログに・・・ Mar 29 18:08:02 hostname kernel: printk: 48843 messages suppressed. Mar 29 18:08:02 hostname kernel: TCP: time wait bucket table overflow Mar 29 18:08:07 hostname kernel: printk: 54962 messages suppressed. Mar 29 18:08:07 hostname kernel: TCP: time wait bucket table overflow Mar 29 18:08:12 hostname kernel: printk: 648
サイバーエージェントを退職します - 元RX-7乗りの適当な日々
私事ですが、タイトルの通り、(株)サイバーエージェントを退職します。昨日8/31が最終出社でした。正確に書くと退職日はもう少し先です。 入社日が2010/09/01だったので、ちょうど丸5年が経ちました。在籍中は、社内外の皆様に多くのご協力を頂き、様々なことにチャレンジすることができました。本当にありがとうございました。 5年もやっていると、それはもう毎日飽きないくらい良い事も悪い事も色々ありましたが、エンジニアとして技術面、および人間として考え方の幅が大きく広がったと思っていて、良い成長機会を頂けたと思っています。 会社として伸び盛りの重要な大規模サービスやプラットフォームサービスに大きく関われた事、様々な技術的挑戦をさせてもらえた事、その上でそれなりの事業貢献ができた事、そして多くの優秀なメンバーと共に刺激を受けながら仕事ができた事、その全てが素晴らしい経験となりました。 私がやってき
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々
HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe
HAProxyを透過型のプロキシとして使う(HAProxy with tproxy) - 元RX-7乗りの適当な日々
HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
Amazon EC2インスタンスガチャをやってみました - 元RX-7乗りの適当な日々
歴史のあるクラウドサービスは、どこもそうなってしまう傾向があるとは思いますが、ホストサーバでの実CPUのアーキテクチャ・世代の違いで、サーバインスタンスのCPUパフォーマンスに微妙な差がついてしまいます。 2006年よりサービス提供しているAmazon EC2でもその傾向があることは割と知られていて、同じ性能だと思って並べて使っていたサーバインスタンスが、同じ処理量にもかかわらず使っているCPUリソースに差がついている、なんてことが起こります。 con_mameさんも、以下のエントリで書かれていますね。 EC2で同じECUだけどCPUは違う - まめ畑 昔は、us-eastでm1.smallのインスタンスをよく使ったもので、その頃はいつもAMDのOpteronプロセッサでしたが、最近では、ほとんどIntel Xeonですし。 ということで、現時点(2013/10)で、EC2インスタンスで使
AWS東京リージョンとBGPピアを確立するとレイテンシはどう変わるか＋α - 元RX-7乗りの適当な日々
参考までに、AWS(Amazon Web Services)までの通信経路上のASパスの数が短くなったら、どれくらいレイテンシが変わるのか計測してみました。 注意事項として、この手の話は、もちろん環境によって結果が大きく変わるので、参考程度にしかならないかもしれませんが、軽く読んでみてください。 ※ 少々長いので、時間がない方は、最後の"考察・まとめ"だけを読んでもらえればOKですｗ BGPピアを確立する？ 通常、インターネットで目的のホストと通信を行うと、途中途中で多くのネットワーク機器を通過することになります。選択される経路は、接続するネットワークによって大きく異なりますが、(もちろん)そのネットワークからの最適な経路が選択されることにはなります。(ルーターで設定されている) で、当然そのルートは短ければ短いほど、ネットワーク距離が小さくなり経由する機器の数も減るので、レイテンシ(遅延
tracerouteの色々 - 元RX-7乗りの適当な日々
インターネットのネットワークに多少なりと興味がある方なら、指定の目的地までの経路探索をしてくれる、みんな大好きtracerouteコマンド。 そんなtracerouteの色々をメモしておきます。 tracerouteの仕組み 既に多くの解説サイトがあるので、そちらに譲りますｗ tracerouteはTTLを1ずつ増やしながらパケットを送信することで、経路情報を取得する。 TTLとはパケットの生存期間を表し、ルータを1つ経由することに1ずつ減算される。 ルータはTTLが2以上のパケットが届いた場合、TTLの値を1だけ小さくし次のルータへ転送する。 TTLが1のパケットが届いた場合、届いたパケットを破棄しICMP time exceededパケットを送信者に返す。 tracerouteはまず、TTLを1にセットしたパケットを送信する。最初のルータに届いた時点でTTLがゼロになり、ICMP ti
Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々
とりとめもなく書いてみる。主にルーキー向けです。 サーバの運用とかやっていると、不定期ではあるが、たまにタイトルのようなディスク容量が逼迫する話題に直面します。 まぁ、それが起こるのは一旦良いとして、みんなこういう時、どうやって調べているのだろう？ とりあえず、僕がどうやってるか書いてみます。 何はともあれ現状確認 みんな大好き"df"コマンドです。細かい説明は省きますが、各パーティション・ファイルシステムごとにディスクの使用状況を確認。 # df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/sda3 130G 88G 36G 72% / /dev/sda1 494M 23M 447M 5% /boot tmpfs 12G 0 12G 0% /dev/shm正確とは言いませんが、だいたいどのパーティションにどのくらい容量が空いているかが確認できます。 ど
AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々
昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。 現時点の情報のスナップショットとしてログがわりに残しておきます。 ASN (AS番号) まず、以下のサイトで調べてみると、、、 http://bgp.he.net/search?search[search]=Amazon&commit=Search この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。 AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ) Peerの内訳は以下のリンク先から確認できます。 http://bgp.he.net/AS16509#_peers ざっくり確認
「MySQL Casual Talks Vol.4」のエア参加レポート - 元RX-7乗りの適当な日々
少し前ですが4/17に、例によってガチュアルっぽいカジュアルトークが繰り広げられてると予想される「MySQL Casual Talks」の第4回目が開催されました。 駄菓子菓子！ 今日、MySQL Casualだったのか。すっかり忘れてたわ・・・。(過去3回皆勤賞)— Y.Namikawa / id:rx7 (@namikawa) April 17, 2013 忘れてた・・・(´･ω･`) ｼｮﾎﾞｰﾝ 過去、MySQL Casualのブログエントリ書き続けているし、今回参加してないけど書いておきたいところだ。そうすることで心は参加。皆勤賞は守られる(違— Y.Namikawa / id:rx7 (@namikawa) April 17, 2013 過去3回とも参加しブログを書いていることもあって、ふとこんなtweetをしたのですが、、、 @namikawa 書いていただけたら次回なんか贈
Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々
さて、またまた昨日のエントリ「Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編)」の続きです。 ここまでの経緯は以下。 Amazon EBS の性能ベンチマーク その1 (Standard編) Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) ここまでのベンチマークでは、StandardタイプのEBSボリュームを使っていたのですが、ここからは、必要とするIOPSを設定することが可能な"Provisioned IOPS"なEBSボリューム(プロビジョンドIOPSボリューム)を使って性能を計測してみたいと思います。 # 個人で Provisioned IOPS ボリュームを使って高負荷テストとかクラウド破産まっしぐら。 ベンチマークの条件の詳細等は、上記のこれまでのエントリからご確認くださいませ。 今回ベンチマークの対象とす
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/ によると「
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ベンチマークをとってみた -
muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
iPhone4Sの背面ガラスの修理代が、Apple Storeで意外と安かった話 - 元RX-7乗りの適当な日々
もう1ヶ月以上前の話なんですが、@masudaKのiPhone4Sが落下してバキバキに割れる事故に巻き込まれてしまいまして、僕が修理代をもつことになりました。 で、@masudaKと話したところ、綺麗になるならOKということだったので、Apple Storeでの修理事例とあわせて、巷のiPhoneのガラス修理をしてくれるお店をいくつか調べていたのですが、どうも背面のガラスに限った話をすると、本家のApple Storeで直すのが安価とのこと。 ということで、渋谷のApple Storeに行ってみると背面のガラス修理は「2,800円」とのことだったので、直していただきました。 (他のガラス修理お店(渋谷界隈)では、背面だと3,800円〜くらいの価格帯でした。) 修理時間もおよそ10分くらいで、お店をブラブラしているうちに終了。正規店でお安く修理できるのなら言うことないですね。 before
DNSラウンドロビンを使った時にアクセス・負荷が偏る話 - 元RX-7乗りの適当な日々
昨日に続き、アクセスが偏る系のエントリです。 なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。 DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。 基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。) この事は、Wikipediaの該当ページにも記載されています。 主にIPv6における宛先アドレス選択アルゴリズムとして定義され
自動車の複数社による同時査定で、一般ディーラー査定よりかなり高額で売却できた話＋RX-7ドナドナ記録 - 元RX-7乗りの適当な日々
まず、このブログの冠にも付けていた僕の愛車、RX-7(FD3S)を売却しました。 この件については、一言で語りきれず、断腸の思いというか苦渋の決断をしました。 売却にあたっては色々と考えた結果、自動車の一括査定(しかも複数社による同時査定)をしていただいたのですが、僕のRX-7は元々非常に特殊な車＆チューンドカーということもあってか、ディーラー査定よりかなり高額で売却できたことと、同時査定に関する情報(体験談や交渉の詳細)がネット上にほとんど存在していないので、僕が得たノウハウを含めて、ここにログを残しておこうと思います。(スケジュール通り、無事トラブルもなく入金いただいたので。) 尚、今回の前提となる車は、既に絶版車ですが、十年落ちの中古車でもグレードや程度がよければ、当時の新車並みの300〜400万という価格で売られている超人気スポーツカーなので、全ての車で今回のようなケースにはならな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
