はてな認証API - naoyaのはてなダイアリー
はてな認証APIをリリースしました。 http://auth.hatena.ne.jp/ 2月末に Flickr の API を調べたりしてから、いろいろ他のことをやってたりしてちょっと時間が空いちゃいましたが、先週合宿にいって一気に仕上げました。一緒にはてなフレームワークに梃子入れしつつ作ったりしてたので思ったより時間がかかってしまった。 とりあえずは、はてなのアカウント名を外のアプリケーションで使える、というところまでできるようにしました。Flickr API とかだと、ここでトークンが取得できてさらにそのトークンを使って写真を投稿したりプライベートな写真を取ったりいろいろできるのですが、その辺はおいおい。 ここが使いづらいとかこういう風になってた方がいいというリクエストなどがありましたら是非教えてください。トラックバック、コメントそのほか何でもいいです。よろしくお願いします。
CodeZine にて KOF 2008 の記事と補足 - naoyaのはてなダイアリー
大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。 CodeZine で先日の KOF 2008 (あらかじめ言っておきますが King of Fighters ではないですよ、関西オープンフォーラムです) の発表を記事にしていただきました。ありがとうございます。 発表資料は以下のエントリーにありますので一緒にご覧いただければと思います。 http://d.hatena.ne.jp/naoya/20081111/1226395400 さて、記事内容について少し補足をしておきたいと思います。 メモリとディスクの速度比較について 「メモリはディスクの 150 倍」という話ですが、その後知人と話して検索のインデックスをシークする場合などは ms 対 ns くらい違
さくらインターネット移行記#5 久しぶりの移転作業
だいぶ間が空いてしまいましたが、久しぶりのデータセンター移行記です。 アンテナ、カウンター、検索を移転 完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。 サーバールームからサーバーを運び出します。台車が大活躍です。 ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。 アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハード
さくらインターネット移行記#2 VPN越しのMySQLレプリケーション
前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを
WEB+DB PRESS Vol.37 - naoyaのはてなダイアリー
見本誌届きました。今月の連載は UNIX ネットワークプログラミング入門と POE について。IO::Socket でソケットAPIをいじりながら echo サーバーを並行処理なし → fork → IO 多重化まで発展させていき、イベント駆動でネットワークプログラミングしたい故に POE 導入...というところまで解説しています。 次回後編は POE の詳しい使い方を中心に、面白い POE::Component::* を各種紹介するといったところまで書ければと思います。 今月号の見所はやっぱり廣瀬さんの LVS の記事ですかね。あと Flex2 開発入門とかも。Flex 盛り上がってきてますね。
naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか
Linux には tmpfs という便利なファイルシステムがあります。 $ mount -t tmpfs -o size=64m tmpfs /dev/shm $ mount -t tmpfs -o size=64m /dev/shm /var/tmpとすると、/var/tmp がディスク上ではなくメモリ上に作られたファイルシステムとして mount されます。なので、/var/tmp は I/O 時にディスクI/Oが一切発生しない高速なディスクとして使えると。いわゆる RAM ディスク。(もちろんサーバーの電源を落とすと保存したファイルは消えます。) この tmpfs はなかなかに便利で、キャッシュとかそういうものでディスクにおいてたものここ置くと、ディスク I/O がカットできて超高速になります。はてなでは MySQL のスレーブの MyISAM のファイルを tmpfs において、オ
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
naoyaのはてなダイアリー - del.icio.us に関するつぶやき - その2
弾さんからツッコミをもらったので、返答しておく。 「警鐘」って、なんか小さくても堅実にやって来た町工場が大企業に札束でひっぱたかれて身売りみたいな印象があるけど、少なくとも今回のそれは違うよ。だって、どうみても始めから大企業に売りつけるために作った会社だもん。 警鐘っていうのは「ニュータイプウェブ企業は自社で売り上げ上げて食ってくあるいは IPO するとかってのは無理っぽい、みんな買収目当てでやってんだよね」って世間の人が言い始めるかもしれないよっていう点ですよ。もし、そういう人たちが言うようにこれから先のウェブ企業に買収しかゴールがないってのは、全然夢がないし、そういう意見ばかりが目につくようになってほしくない、そういう意味。 で、del.icio.us が端から買収目当ての会社だったかもしんないじゃん? っていうのはその通りだと思わせる点は弾さんが挙げてくれてる通り。 このとき Blo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
