Serverの最近のブログ記事

さくらインターネットのVPS

管理人 (2010年9月 1日 21:30) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　いつもお世話になっているさくらインターネットですが、VPSの販売をしているのを知って検討してみようと思った。なんせ月額980円からなのでメモリーが心配ではありますがうまく行けばサーバー代を10分の1以下にできるかもしれない。最近専用サーバーを更新したばかりでこの専用サーバも5年目に入るのですがそろそろ危ないかなっと・・・。それに専用サーバーを共用サーバとして組むよりVPSで数の勝負した方が設定が楽というのもある（リスク分散的な意味で）。

さくらのVPS｜VPS（仮想専用サーバ）はさくらインターネット
http://vps.sakura.ad.jp/

現在のサーバー費用ですが、専用サーバが113,190円でメールの為に残している旧サーバ(共用レンタル)が15,000円の合計128,190円です。で、現在サービス停止不可なドメインは2つなので2台借りるとすると10,780円×2で21,560円(1つはこのブログのドメインでもう一つは開発用の公開サーバなのでDBを開発側に設置するという分散を考えて)。これならアフィリエイトだけで赤字を防げる気がする。

現在のサーバーの残り期間から、移行は来年の春くらいになりますがCentOSなら自宅で何度も移行シミュレーションできるし、あとはMTのチューニング次第ってところですね。

メールサーバが12月末更新なので多分解約申し込みは11月下旬が期限になるはず、それまでにはメールサービスを移行する必要があるので11月初旬申し込み、中旬に移設作業が妥当かな。無料2週間が契約期間に加算されないのであれば10月下旬申し込みというのもあり。もちろん2台。メールだと対した移設はなくてユーザに事前通知が必要なぐらい。これに関してはアカウント情報の変更内容をVPS借りる前に確定して10月の段階で告知かな。次に12月に入ってからはウェブサーバの移設になりますが、こちらの期限は来年7月下旬なので6月までに移設完了していればOK。軽いサイトから順次移行します。今はIPv4を16個も確保してますが、今のところ公式SSLサイトが無いのでVPSにしても無問題。メールも使いたいとかSSLサイト構築したいといった要望が出たらその数だけVPSを増設すれば終わりｗ

メールサーバのマルチドメイン・マルチユーザは正直面倒くさい。VPSで安ければリスクヘッジも含めて楽だと思った。

load average 30!

管理人 (2010年8月31日 23:32) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
最初にお詫び申し上げます。時々ご不便をお掛けし申し訳ありません。非常にアクセスしずらいなーと思い気になってサーバーログインしてみたらload averageが30を超えてました。どうもperlが大量に立ち上がって暴走していたみたいですがmod_perlとMT4の相性が悪くて使ってないのと、MT4側に外部からアクセスされるプログラムの一部でパフォーマンスが悪く。DDosでも無いのにサービスダウンに近い状態になってました。

これはどうしようか。MT5に切り替えたら、MT4のスクリプトは全て起動しないようにするかな。。。

やっぱりVMware重すぎ・・・

管理人 (2010年8月25日 23:45) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　ここ半年ぐらいは64bit版OSが使えるからという理由でVMwareを使っていますが、複数台同時稼動させて通信関連のテストを行おうとするとホストOSが激重になるんですよね。WinXP 32bit版ですけど。(Win7 64bitの方は今のところ大丈夫)。という事でVirtual PCも捨てがたく再インストールしました。んー。

Zabbixとか

管理人 (2010年7月12日 23:24) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
サーバー監視を行う統合ソフトウェアとしてZabbixというのを最近知りました。今まで自作であれこれやってて辛いものがあったのでこれを導入してみようかな。

ZABBIX-JP - Un-Official Support Page
http://www.zabbix.jp/

富士通とオラクルがHDDをSSDに変えたらデータベースはどれだけ速くなるか実験

管理人 (2010年4月28日 09:15) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　ちょっと前に見つけたこのエントリー。一般的に物理的な理由でSSDの方がランダムアクセスにの性能に優れる事をこの実験でも証明されましたが、CPUが先にボトルネックになる程とは・・・。これSSDは速いからって深く考えないで移設したら、JOINが多く非効率なSQLが走った時にサーバーが飛びやすいって事だよな・・・。ユーザ向けのDB等はSSDを利用してレイテンシを下げて、バッチ系は完全に切り離さないとマズいな、予算の問題もあるけど。

HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験 － Publickey

スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

ここでスクリプト言語がネックと書かれていましたが、基本DBサーバーは運用上分けていたりするでしょ？それにこれはDBが使用するCPUの負荷がボトルネックという事だと思うので、スクリプト言語使ってパフォーマンスが遅いほうが全体として助かると思う。

スクリプト言語でパフォーマンスを上げる方法はいくつかあるし、コンパイル不要で稼動する便利さは手放せないと思いますよ。通常手を加える必要が無いテンプレートエンジンやライブラリはスクリプト言語で書くメリットは少ないからそういうものは積極的にバイナリに変えたりしたいところですね。

現在発生中のDNS障害につきまして

管理人 (2009年11月27日 23:00) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
本日、ライブドアデータホテルパトロールより、長時間に渡るアクセス障害の連絡を頂き、該当ドメインの調査を進めたところ、開発者向けに提供しているドメインの一部においてDNS障害による名前解決が行われていない事が判明いたしました。

検知時刻：11/27 17:11:57
最終検知：11/27 22:16:46
DNSサーバー1：01.dnsv.jp
DNSサーバー2：02.dnsv.jp

ドメイン 取るならお名前.com
【DNS設定/転送Plus】名前解決不具合の発生

この障害に関する影響につきましては下記の通りとなります。
ウェブサービス：未提供の為、影響なし
メールサービス：対象ドメイン宛のメールでエラーが返されている可能性がございます。

追記：23:53
DNS障害が再発しております。現在も障害継続中。
検知時刻：11/27 23:21:37
お名前.comの告知の更新はありません。

追記：0:57
11/28 0:41:39の検知報告を最後に異常が出ておりませんので0:47を復旧時刻といたしますが、DNSの性質上、完全復旧まで24時間かかる場合があります。(キャッシュタイム24時間に設定しているため)
お名前.comでは0:15に復旧報告が告知されております。

以上でこの件はクローズさせて頂きます。

追記：2:26
検知時刻：11/28 1:46:47
障害がまた再発しているようなのでしばらく様子見てましたが、お名前.comの告知が更新され復旧に至って無いことが確認されました。

緊急対策として

緊急の場合は、外部のDNSサービス（"無料DNS","Free DNS" などで検索）などをご利用いただきますようお願い申しあげます。
手順：
1.外部DNSサービスにてレコード設定
2.ドメインNaviにてネームサーバー変更

と紹介されてますがISPのキャッシュDNSじゃあるまいし、そんなにwhoisの内容をコロコロ変えられますかって、伝播のこと考えたら永久変更だな。

ところで何でお名前.comのDNSはプライマリとセカンダリのIPアドレスが並んでるんだ？
ISPならパフォーマンスを上げるためのキャッシュDNSを地域の経路に設定するので同じネットワーク内に入るのは理解できるけど、ドメイン管理会社のDNSとしてはありえない設定じゃないのか？
同一施設においているのもどうかと思うがIPアドレスが並んでいるのはネットワーク上同じ経路を使っているのが確実でタブーというか論外。
再発防止策にこの点の改良が見られない場合は残念ですが別会社に移管の手続きを進めたいと思います。

追記：10:10
最終検知：11/28 6:56:44
現在は正常に稼動しております。お名前.comではサーバー増強による対策を行われたと告知が着ておりましたが、サーバー負荷が主な原因のようです。バックボーンや経路上の装置の障害ではないようですがプライマリ・セカンダリのIPアドレスは並んだままですね。今回は応急処置ということで理解しますが同一施設でのDNS運用は今後のリスクを考えるとお任せできないので週明けにも変更します。

バージョン違いMySQLの同居

管理人 (2009年8月 4日 02:15) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　同じバージョンのMySQLを2台同じサーバーに入れたりというのは開発環境でやったことがあるのですが、双方とも自動起動してバージョン違いかつ文字コード違いという環境は初めて入れた。結論としては自動起動スクリプトがまるで複数導入を想定していないというのが分かったくらいかな。

やってみた構成はこんな感じ。

  • rpm版同士での複数インストール
    これは普通に競合するのでNG

  • 既存のMySQLクライアントとPHP-MySQLコネクタを残して、MySQL公式サイトのrpm最新版(Serverのみ)をインストール
    これも競合。MySQL公式サイトのものはServerとClientで２つに分けているが、RedHat公式のMySQLはServerとClientとその両方で使う無印パッケージの３つ分かれ、無印とMySQL公式のパッケージで競合を起こす。

  • 既存はrpm版で別途ソース版を入れる
    これは問題なし、自動起動スクリプトは改造が必要

  • 既存がソース版で別途インストールもソース版
    問題は無いがソース版同士なので全ての設定を別に分ける必要が出てくる。自動起動スクリプトは改造が必要。
自動起動スクリプトの改造が必要なのは、configureの設定内容を無視しているのでそのまま使えばデフォルトの構造でmy.cnfやpidファイル、sockファイルを探しに行くという恐ろしいワナがある。結局自動起動スクリプト上のmysql_safeコマンドの行に--defaults-file=[my.cnfのパス]で設定が必要。ちなみにこのオプションは最初に記述しないとエラーになります。他にはDBの初期化(mysql_install_db)をするときに既存のDBを破壊しないように念のためバックアップを取った上でオプションでdatadirやdefaults-fileを設定し回避すること。これは理由がわからないのですがスレーブ用に構築する予定のDBで初期化するときに最初からmy.cnfよりbin-logを抜いていたらエラーになった。これは初期化にはバイナリログが必要だったのか、中途半端なコメントがまずかったのかは不明。別に初期化の時にバイナリログが出されてもたいしたこと無いので別に良いのですけどね。

参考

またレプリケーションも本格的に負荷分散しようとしたら参照系で不要なDBやテーブルを持ってきたくないという事がありました。こちらの設定はスレーブ側のmy.cnfの[mysqld]内に
replicate-do-table=dbname.table
replicate-do-db=dbname
といった感じで追記するだけ。

また文字コードの設定で[mysqld]内に
default-character-set = utf8
だけでなく
skip-character-set-client-handshake
を設定するとPHPから接続したときにいちいち「SET NAMES」を設定しなくても良くなるし、他のセクションにdefault-character-setを入れなくても文字コードが統一される(status;やshow variablesで確認)。

[MySQL] 特定データベース、特定テーブルを指定したレプリケーション設定 | 半袖野郎 blog.hansode.org

あと大きなバッチを使うときに気になるのがメモリ使用量なのですが、折角１行ずつ取り出すのに一斉に配列に入れようとするのはセンス無さ過ぎで見つけ次第指導するレベルなのですが、また全件必要でないのにどうせ詮索スピード変わらないからという理由でLIMITを使わないのもメモリの事を考えてない証拠なのでこれもダメ、でもまさかmysql_query関数の結果が一旦全部メモリにキャッシュされるとは思わなかった。PHP上ではどう見てもメモリが溜まるような処理を書いてないのにメモリ不足になるのはこれのせいだった。そのときはmysql_unbuffered_queryを使いましょう。mysql_unbuffered_queryの制約としてはmysql_data_seekが使えないことや全ての行をフェッチする必要があるという事なので件数の絞込みはしっかりLIMITで設定しましょう。スピードは多分遅くなると思いますがバッチ等では消費メモリの上限を抑えられない方が問題なので。

PHP:SQLクエリのメモリ消費量を抑える:mysql_unbuffered_query

今更過ぎますがINDEX貼るとINSERTが遅くなることに気付く

管理人 (2009年7月13日 23:06) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　今日はMySQLに対し数千万件のデータ生成バッチを組んでましたが、重複禁止のデータの為主キーにしていたら200万件超えた辺りから見る見るデータ挿入が遅くなる。これは挿入のたびに重複検査するから遅くなるのかとうっかりしてました。それでINDEXなら大丈夫だろうとキーの種類変えて再実行したら主キーのときに比べれば若干マシなのですがそれでも500万件超えると極端に遅くなる・・・。何でだろうとちょっとSELECTしてみたらINDEXのフィールドはソートされるのか！今までメモリにキャッシュしてるだけかと思ってた。こんなのDBエンジニアやシステム開発者では常識なんだろうな。。。結果、INDEXを全く付けないテーブルだと最も速い（挿入以外の処理をしない）事になりますが当然検索や集計には向かないので記録用テーブルと集計用のクローンテーブルって必要なんだな・・・。並べ替え不要な条件だったら速いのならログ関係はタイムスタンプのみINDEX貼って、集計クローンテーブルは集計期間で拾って作成すると効率よさそう。（やってみないと差が分かりませんが）

これはMySQL5.1のパーティショニングを使ったときはどのような挙動するだろうか？INDEXなしは余りパフォーマンスが変わらなくて、INDEX付きが結構速くなり、主キーだとちょっと速くなりって感じかな？

PostgreSQL8.4リリース

管理人 (2009年7月 2日 23:15) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　7月1日(現地時間)にPostgreSQL 8.4がリリースされました。1年5カ月ぶりの新版ということだそうですがMySQLから見るとそれでも早いなぁという印象です。

PostgreSQL 8.4リリース，1年5カ月ぶりの新版は293件の新機能と改良：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090702/333088/

はてなの自作1Uラックマウント

管理人 (2009年6月26日 00:30) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　とても興味深い記事です。そういえば「はてな」のサーバーはさくらインターネットに収容してましたね。空調がしっかりしているラックないなら筐体カバーいらないのかな？ボードむき出しのままマウントするのはインパクトあるけどラックマウントは結構ファンによる風が強いはずだから冷却効果が凄そうだ・・・。

1Uラックマウント可能なサーバを自作する - marqs blog
http://d.hatena.ne.jp/marqs/20090622/1245670553

[PR]さくらインターネット×はてな、自作サーバを語り合う - はてなブックマークニュース

19インチラック買おうかな？

管理人 (2009年6月21日 23:59) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　先週から不用品等整理してコンパクトにしようとしているのですが、PC等も整理したほうがいいかな？っと思い10U程度の19インチラックを買ってスッキリその中に纏めるのはどうだろうと検討中。というかメインがノートPC使いなのでプリントサーバ代わりにしか使わないデスクトップはもういらないんですよね・・・。あとバックアップもビデオなんて撮ってるとDVDなど光ディスクでは全然足りないのでRAID1のNASとかあったほうが良いかな・・・など考えてます。

☆サーバーラック 19インチ☆「サーバーラック ラックマウント」格安販売激安特価価格 小型 耐震 防音

ここでサンワサプライ製のラックが安く売っているので、ここでラックを購入して、デスクトップPCが必要なら

ラックマウントケース - HEC Online shop

こちらでケース買って乗せ変えようかなとか考えてます。ちなみにNASは

“TeraStation PRO” RAID機能搭載 NAS ラック対応タイプ|TS-RHTGL/R5シリーズ

ラックマウント型のTeraStationを検討しています。

PCを4Uにすればあまり奥行きの無いラックでもよさそうだけど、Linux用とWindows用積んだらそれで終了というのも悲しいので奥行きも確保して2Uにしようかな？ラックマウントのLinuxサーバ導入するかどうか未定ですがするとしたらUPS内蔵静音電源搭載にします。んで木製の自作ラックはポイッっと。

Doblogが5月30日にサービス終了

管理人 (2009年4月24日 23:45) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　一部サービス再開からは特に状況を追っていませんでしたが、最終的に99%以上のデータ復旧ができて停止したサービスも再開できていたんですね。担当の方は大変苦労されたと思いますが、この経験は今後の障害対応に役立つものと願っております。

2月に障害発生の「Doblog」。5月30日をもってサービスを終了
http://internet.watch.impress.co.jp/cda/news/2009/04/24/23277.html

映画に出てきそうな地下データセンター

管理人 (2009年4月13日 01:14) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　核燃料庫だった所をデーターセンターに改装して出来たそうです。水爆にも耐え、予備電力も潜水艦用のものを使用するため停電があっても暫くは大丈夫らしい。それにしても綺麗な秘密基地みたいだ・・・。

映画に出てきそうな地下データセンター - GIGAZINE
http://gigazine.net/index.php?/news/comments/20081117_super_designed_data_center/

データセンター関連で探したらこういうのも見つけました。コンテナラック？ともいうのかな。

マイクロソフトの考える屋根がない衝撃的な第4世代型データセンター構想 - GIGAZINE

スケーラビリティと設備投資の計画の立てやすさで今後増えそうですが、平地の少ない日本じゃ難しいですね。そういえばニコニコ動画ってもうデータセンターにサーバー置くスペース無いって言ってましたね。動画は安定した帯域確保するのにも大変でしょうから、２ちゃんねるみたいにアメリカにサーバー設置というわけにも行かないような気がする。

GoogleサーバのUPSは12Vバッテリー

管理人 (2009年4月 6日 03:15) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
さすがGoogleは賢い、私が自宅サーバーにノートPCを使うのも同じ理由でUPSでバックアップ電源を統合するよりも個々にバッテリーを置いたほうが安全なんです。社内にサーバーを設置しているところでUPSを取り付けているところを何箇所か見たことありますが、設置の仕方に問題あるところの方が多かったですね。UPS自体容量も出力も有限なのにディスプレイ含めてサーバー何台も繋いでいるとか、UPSのバッテリーに寿命がきてしまったばかりに電源障害を起こしそれにぶら下がっているサーバー全台計画停止などUPS自体がボトルネックになるような運用されているところがありました。

個人的意見としては外部UPSはルーターやHUB等あまり電力を消費しない組み込みネットワーク機器のバックアップ電源として統合して停電時でも通信を継続できるようにし、サーバーは個々にUPSを用意してリスク分散をするのが良いと思います。ディスプレイは基本UPSいらないでしょ。

実はUPSは小分けしたほうが電源容量あたりのコストパフォーマンスも良かったような気がします。デスクトップPCでもアキバに行けば5インチベイ内蔵型で直列タイプのバッテリーがあるのでそういったものを利用するのも良いと思います。しかも外部UPSより安い。

記事では変換効率の上でもパフォーマンスが良いことを上げられていますが確かに内蔵型であれば一往復分のAC/DC変換を省略できますからね。あとスペースもかなり省略できる。

Googleのサーバは12Vバッテリを搭載 - スラッシュドット・ジャパン

Google uncloaks once-secret server | Business Tech - CNET News

Googleの検索エンジンはgrepってホリエモンこと堀江貴文さんのブログにちらっと書かれてました。あれはそうだとしたらホントに目からウロコ。

追記：2009/04/06
翻訳記事がありました。
グーグル、自社設計のサーバを初公開--データセンターに見る効率化へのこだわり:スペシャルレポート - CNET Japan
http://japan.cnet.com/special/story/0,2000056049,20390984,00.htm?ref=rss

とうとうメインの自宅サーバー故障

管理人 (2009年4月 1日 07:45) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
3年半程前に構築したメインの自宅サーバーが完全に故障してしまった。正確にはメインは半年前に故障していてHDDを半壊状態のサブサーバーと交換して騙し騙し使っていましたが、そのサブサーバーもダメになった。どちらもマザーボード故障。MMO Project用に構築した開発向けサーバーがこれで完全にぶっ飛んだという事です。。。ドメインやメール関係は外部のレンタルサーバーに移設済みなので実質的な影響はないのですが。しばらく開発環境はVirtualPCでなんとかしてその内VPS用にハードウェア一台購入することにします。

auのIPアドレス帯域が変更されたようです。

管理人 (2009年3月11日 20:00) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　ke-tai.orgサイトより。auのIPアドレス帯域に変化があったとの記事がありました。
確か去年凄い細分化されて設定が面倒だった記憶がありますが、多分移行を行っていたのかもしれません。

　今回はルールの削除ということで突然携帯からアクセスできなくなるわけではないのでそういう意味で緊急の対応は必要ありませんが、同じサイト内でIPによるPC/携帯割り分けを行っているサイトが対応が必要になりますね。

ke-tai.org > Blog Archive > 2009年3月10日付けでauのIPアドレス帯域に大幅な削除があったようです
http://ke-tai.org/blog/2009/03/10/auip20090310/

レンタルサーバーの価格サイト

管理人 (2009年2月27日 13:00) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　レンタルサーバーの価格調査をしていましたら、下記の価格比較サイトを発見しました。現状では情報量が少なくレンタル事業者のサイトへジャンプしないとプランの数が確認できないのですが、今後が楽しみです。ちなみにランキングは参考になると思います。

レンタルサーバーデータベース - 価格比較・口コミ
http://www.serverdb.info/

PHPでのSSL運用に注意

管理人 (2009年1月 6日 14:00) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　下記URLにて重大なバグについて警告がなされています。まず条件として
  • Apacheモジュールとして動作させていること
とあり、どのような被害が想定されるかというと秘密鍵を盗まれると書いてあります。さらに防止方法としてApacheモジュールとして動作している共有ホスティングは使用しないとありました。

詳しいところは確認していないのですが、これらの内容よりSSL鍵が盗まれるのはサーバー外からのアタックでは無くて、同一サーバーにログイン権のある他者という事らしいです。対処方法に共有レンタル使うならVPSに移行するように書かれていることからそうだと思います。しかもApacheに使う秘密鍵はサーバ障害時の復旧作業を短縮化させるためパスワード解除されている場合があるので恐ろしい話です。

現行版のPHPに任意メモリ参照バグ - 攻撃コード付き
http://blog.ohgaki.net/cve-2008-5498

さくらインターネット西新宿データーセンターで発煙事故・復旧

管理人 (2008年12月21日 01:00) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　昨日の事故は物理的な問題でもあり大変だったと思います。今回の西新宿データセンターは確かハウジングサービス用だったと思うのでスラッシュドットのコメントの占有サーバというのはハウジングを含めた予測だと思う。専用サーバーサービスを運営しているデータセンターは立ち入り出来ない施設のはずです。

　電源障害が発生したというのもハウジングなら可能性高くなりそうですね。顧客がサーバーを持ち込むので定格通りに運用されているかどうかチェックが難しいと思います。

　今回の事故でGREE、シーサー、So-Net等のSNS/ブログサイトがサービス停止したようです。リアル炎上とか言われても笑えない冗談。

SAKURA Internet // 2008年12月20日 「西新宿データセンター」における電源障害の復旧状況に関するお知らせ
http://www.sakura.ad.jp/news/archives/20081219-002.news

スラッシュドット・ジャパン | さくらインターネットのデータセンター、リアルに炎上してサーバダウン
http://slashdot.jp/it/article.pl?sid=08/12/19/0835205

さくらインターネットのデータセンターで電源障害、グリーやソネットなどが停止：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20081219/321823/

ライブドアがIPv6対応を支援

管理人 (2008年12月16日 08:18) | コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
　自分でサーバーを持っていても中々IPv6の実験ってできないですね。それはプロバイダが提供していない、設定が不明といろいろありますが今回ライブドアはIPv6の実験環境を提供してくれるとの事です。いつかはIPv4を捨てIPv6に移行するとしたら早めにIPv6用のサーバー構築をしっかり勉強してみたいと思います。

IPv6対応をlivedoorが支援します！ | EDGE Co.Lab v6
http://labs.edge.jp/colabv6/
« Project MMO | メインページ | アーカイブ | Sports »

サイト内を検索

アーカイブ

タグクラウド

カテゴリ