ただつらつらと日記が書かれていくようです。
しばらくぶりの更新でこんなことを書くのもアレだけれど、今年のお正月用の日本酒に、秋田の地酒「高清水」の純米酒を選んでみた。
まぁ、なんというか、ちゃんとした日本酒だなぁというか、なんだか”しっかり”って形容詞がぴったり来る感じですな。
元日の朝っぱらから数の子とかまぼこを肴に「高清水」を2合飲んじゃいました(…だから、風邪が素直に治らなかったのかっ)
さて、SSL証明書の有効期限が近づいてきたなぁ…と思ったので、前々から気になっていたGoDaddy.comでSSL証明書を買ってみることにした。
そもそも、SSL証明書ってブラウザとサーバ間の通信の秘匿性を確保するためには必要なものではあるんだけど、PCについては(逆に言えば、ガラケーあたりは除外して考えると)SSL証明書のベンダー間の差違を感じづらい商品だと思っている。
まぁ、確かに、EV SSL証明書なんてのもあるけれど、一般的なサイト利用者を想定すれば、ブラウザのアドレスバー辺りが緑になるなんて野はどっちかというと誤差に等しく、SSL通信を始める際にブラウザがエラーを出さなきゃOKくらいの感覚…が正確な表現だろうか。
SSL証明書を購入する側がそんな感覚なのに、ベンダーによって値段がピンキリだったりするのが、SSL証明書のややこしいところだ。
確かに、購入サポートというか、期限切れになりそうになったら懇切丁寧にリマインドしてくれるとか、簡単にSSL証明書を更新できるとか、そういった部分も考慮に入れる余地はあるけれど、あくまでSSL証明書に付帯するサービスという位置づけに過ぎないと思う。
要するに、PCのサイトとメジャーなブラウザで使えればいいことを前提にすれば、SSL証明書なんて安いもので十分ではないかという結論に至った。
そんなわけで、GoDaddyである。GoDaddyは、アメリカでドメインだのレンタルサーバだのSSL証明書だのを売っているサイトで、国内で売っているSSL証明書と比較すると、破格の安さで提供されている。
例えば、シングルドメインのSSL証明書(SSL証明書を買った組織の存在証明とかしないでドメインの確認だけ行うタイプ)で、だいたい4000円/年くらい。いやはや、これは激安。しかも、複数年契約するとディスカウント(確か、私が買ったときにはお買上額から-10%だったかな)されてしまうという、うれしいサービスまであった。
とりあえず、記憶が曖昧ではあるんだけど、3年分を買って1万円くらいだったかなぁ…と。GoDaddyでSSL証明書を買うまでは、この値段で、だいたい1年分買えれば安いなぁ…という感覚だったような気がする。
ここまでだと、GoDaddyサイコーとなってしまうが、それなりにやっかいなことがあるので、それをメモっておく。
GoDaddyのサイトはもちろん英語。しかも、なまじ日本円で値段が表示されたりするから、うっかり期待してしまうけれど、購入完了まで日本語が出てくることはなかったような気がする。
とはいえ、国内のサイトでSSL証明書を買ったことがあれば、必要な手続きはわかっているはずなので、うろ覚えの英語で必要な手続きをやれば、SSL証明書は発行される…と思う(まぁ、保証はできないけども…)
GoDaddyにお金を支払う際に、クレジットカードも使えますが、PayPalも使えるみたいだったので、私はPayPalで支払い。まぁ、GoDaddyがサイトで商品の値段を日本円で表示しているけれど、結局、ドル建てで決済したような気がするが、どうだったか…と(これまた記憶が曖昧)
もし、PayPalのアカウントもなく、国際決済できるクレジットカードもないとなると…ハードル高いかなぁという印象はあるかなーと(日本とアメリカの銀行間の少額決済とか高そうだし)
一応、手順的には、まずオンラインカート機能を使って、SSL証明書を発行してくれる権利を買って、その後でCSRなんかを入力して、最後にドメインのValidationってことで、ドメインのWHOISに載ってるアドレスに承認を求めるメールを”いきなり”送ってくる。今回はco.jpドメインだったが、JPRSのWHOISに登録されている「登録担当者」のメールアドレスにメールが飛んできた。
国内の某SSL証明書ベンダーから買ったときには、@の左側の候補(info@とかadmin@とか)がいくつか提示されて、どのアドレス宛に承認を求めるメールを送ればいいか聞かれたような記憶がうっすらとあるが、GoDaddyはWHOISを参照してどーんと送ってくる。
そういう意味では、GoDaddyでSSL証明書を購入するつもりなら、SSL証明書を発行する対象のドメインのWHOISをきれいにしておくことが必須だろうと思う。
これまた個人的な印象ではあるけれど、GoDaddyにヘルプ(やっぱり英語)もあるけれど、これがあんまり親切な感じではなかった。日本の某SSL証明書ベンダーのように、手続きを1から終わりまで列記してくれるとありがたいんだけど…そんなわけにもいかず(汗)
結局、お金をいつ払って、CSRをどこで入力すればいいのかとか、結構、慣れないとSSL証明書ベンダー毎にシステムが違ってたりするから、これまたややこしさ満載ではあるんだけど、GoDaddyはその部分について親切とは言い切れなかったなぁと。
まぁ、とりあえず私は無事に購入できたし、GoDaddyのSSL証明書(中間証明書込みで)を組み込んだサイト(確か、プラットフォームは、さくらインターネットのレンタルサーバのビジネスプロ)の方も何事もなく動いているみたいだ。
これをメリットというと少しアレだけど、GoDaddyからディスカウントコードが届くようになってしまった。時折、.comドメインとか.imfoドメインあたりが、期間限定で30%引きになったりするらしい。
とりあえず、今度、ケータイ(ガラケー)を前提から外せるサイトのSSL証明書を調達するのであれば、GoDaddyで十分だと思っている。
追記：
若干のドヤ顔気味で「GoDaddyで十分だと思っている。」とか書いちゃってますが、godaddy.comのSSL証明書よりもイイ感じの証明書を見つけてしまいました。→「また安いSSL証明書を探してみた。」
昨日、会社のルーター(RT57i)がパフォーマンス不足になって、ちょっとややこしいことになったので、勢いよくRTX-1100に交換してみたら、きれいにはまった(涙)
まぁ、もともと使っていたRT57iの設定を流用しつつ、無駄なNAT設定や意味不明な設定を見直そうとしたときに、コンフィグに余計な設定を追加しちゃったのが原因だったことが後からわかる…のだが、ま、その時は気がつかないわけで(汗)
RTX-1100に交換して何が起こったのかというと、RTX-1100に交換してパフォーマンスの向上を期待したにも関わらず、すさまじいパフォーマンスのダウン。
とりあえず、つながっているんだけども、SFTPでファイルをダウンロードし始めたら、スループットがRT57iを使っていた時の10%くらいになってた(涙)
さらに、イントラネットのマシンからイントラネット側のIPアドレスにPingを打ったらRTTがすんごいことになった。ファストイーサネットなLAN(間に入ってるスイッチングハブが2つくらい)なのに、RTX-1100にPingを打つと600msとかかってる(汗)てか、太平洋超えても200msくらいじゃないのか…と。
まず、RTX-1100に余計なフィルター設定をしたんじゃないかと思って見直してみたが、その辺はRT57iの時と変わらず。RTX-1100にすることでハードウェア性能は向上しているはずなので、同じ設定であれば、こんなことは起きるはずもない。
イントラネット側のIPアドレス宛のPingのRTTがすんごいことになっているにも関わらず、RTX-1100のCPU使用率は10%以下のまま。RTX-1100自体が輻輳している訳じゃないことがわかった。
…で、設定を見ながら、ふと目にとまったのがこの1行。RT57iの頃にはなかった設定で、なんとなく追加した1行。
lan type lan1 100-fdx
この設定は、RTX-1100に搭載されてるイーサネットポートの通信速度を100BASE-TXのFull Duplexに固定する設定と。
そういえば、RTX-1100が刺さってるのは、非管理型のギガビットイーサ対応のスイッチングハブ…(汗)あ、やばいかも。
というわけで、この設定を
lan type lan1 auto
に、変えた瞬間にSFTPのスループットもPingのRTTも大幅に改善するわ…と。とりあえず、問題は解消。
なんか、最近、データセンター用のL3スイッチいじってたから、通信方式は固定すべきなんて無意識に思ってたのが仇になった。確かに、データセンタに置かれてるような(高い)スイッチは、スイッチ側で通信方式を固定させられるから、接続するマシンの通信方式を固定しても、うまく接続できるわけで…。一方、オートネゴシエーションにするとややこしいことになるから、わざわざ、スイッチとマシンに設定を施して固定するという背景があることも確かだしなぁ(遠い目)
ただ、ポートの通信方式を設定できないスイッチにマシン(とか、NW機器)を接続するときは、とりあえず、オートネゴシエーション設定にするしか選択肢がないんだろうなぁ…って、そんなことは当たり前ですか、そうですか(涙)
…やっぱり、ネットワークは難しいなぁと…。
とりあえず、なんとなくの勢いで「Xperia」を買ってみた。
スマートフォンを使いたくてムラムラしてたとか、ガラケーに飽きてたとか、そういうことも特にない。まぁ、流行ってるみたいだし、触っといて損はないかなぁくらいの感覚で、それまで使ってた、DoCoMoのガラケー(N-01B)を持ちつつ(ま、ほとんどオサイフケータイのために持ってるようなもんだけど)、2台目として「Xperia」を買ってみた。
8月下旬、ふらっとヨドバシAKIBAに出かけてた。展示されてるXperiaをちょっといじってみて、「これの黒いのください」と店員さんに告げて、多めの書類に名前をいっぱい書いて申し込み完了。しばらくして、ヨドバシカメラのレジにて、シャリーンとEdyで代金を支払って、晴れて「Xperia」が手に入った。
値段は、確か、2年縛りの割引が付いていたので、3.5万円くらいだったかなと。溜まったままになっていたヨドバシのポイントを使ったりして、Edyでお買い上げしてみた。陸マイラーとしては、Edyでシャリーンと行きたいような気がしたけど、本当に正しかったのか…と言われると、ちょっと自信がない。
そういえば、9月になってから、DoCoMoがSPモード開始記念で本体価格の割引を始めた(買った翌日くらいに、キャンペーンの発表がなされるという…)ので、1週間くらい遅く契約していれば、5k円くらいは得したかもしれない。まぁ、残念といえば、8月下旬に買って、当然ながら、パケ・ホーダイダブルを付けたんだけど、スマートフォンでパケ・ホーダイダブルを使ったら、一瞬で上限価格に達するわけで…1週間しか使っていないにも関わらず、1ヶ月分のパケ・ホーダイダブルの上限金額を払わなきゃいけないのはなんとなく切なかった…か。とはいえ、DoCoMoのスマートフォンが欲しいと思う人達は、普通、その辺も考えて、ちゃんとSPモード記念の割引も適用され、パケ・ホーダイダブルの上限金額を支払いつつも、きっちり1ヶ月分使える、9月上旬の契約をされていることだろう。
これまで、N-01Bにパケ・ホーダイ(≠パケ・ホーダイダブル)を付けていたけれど、さすがに2台ともパケホーでがっつりお支払いするのもアレなので、N-01Bはパケ・ホーダイダブルに切り替えてみた。たまにメールが来たり、オサイフケータイのEdyやSuicaのチャージくらいなので、ほとんどパケット通信が発生せず…と。極めて、平和な状態だ。
そんなわけで、「Xperia」が手に入ってしまったわけだけだが、最初の充電をしながら、ふと思った。
「…Xperia、何に使うかなぁ」
続く。
社内の開発用マシンのHDDを交換することになったので、とりあえず、HITACHI製のドライブを買ってみた。
プチプチに包まれたバルクドライブが届くつもりで待っていたら、届いたのは、なんかもう「the リテールパッケージ」って感じの箱入のハードディスク。
外箱には、ご丁寧にHITACHIのロゴまで入っていて、ちゃんと「inspire the next」って書いてあったけど…ここまでする意図はなんだろうという感じ。バルクドライブのまま流通させたほうが安そうだし、こういうところにお金をかけて値上げされても辛いというか、こういうところ値上げされると、他のベンダーのHDDを買いそうになるのは私だけだろうか。(…ところが、こんなしっかりしたパッケージのHITACHI製ドライブがむしろ安かったのはどういうことだろう…)また、外箱には中に入っているHDDの型番を書いていなかったので、HDD好きな人にとっては型番を選べないのも辛いかもしれない。
で、外箱を開けて、中のHDDを引っ張り出してみると、HDDが箱の中でしっかり動かないように梱包されていて、かさ張るけれども、まぁ、これはこれでいい感じ。
日本語で書かれた保証書が付いていた。お買い上げ日から3年間保証らしい。ただ、SeagateのRMAなんかと違って、HDDが保証期間内に故障したら、お買い上げ店に持ち込んで…ということになってるのが面倒くさそうだ。普通に、RMA方式でいいじゃないかと思うのだが…。
もとい。こんなしっかりしたパッケージとバルクドライブを併売するのもナンセンスだろうから、日立が保証を付けてリテールパッケージ売りを始めるということは、そっち方面にシフトしていくということだろうなぁ。…てか、いつから始めたんだろう(汗)
はてなTシャツとかはてなステッカーが当たるっていう、はてなのキャンペーンがあって、応募していたことを忘れかけてたタイミングで当選通知が来た！
というわけで、担当の方からメールをもらって程なくして届いたのが、このステッカー。おぉ、ホントにはてなステッカーだ。
![[はてな]](http://img.f.hatena.ne.jp/images/fotolife/y/y_fudi/20100812/20100812003311.jpg)
とりあえず、職場のPCに一番大きいはてなロゴステッカーを貼ってみた。私のPCは小さめのDELLなので、貼るスペースに困った(笑)加えて、同僚のPCやキーボードにも貼りまくってみた(笑)
はてなのみなさま、どうもありがとうございました！
ちょっと新しいレンタルサーバを調達するか、ということでレンタルサーバのサービスを探していたら、新しいサービスを見つけた。その名も「サーバーカウボーイ」。
…えーと。まぁ、ネーミングはさておいて、レンタルサーバの仕様を眺めてみると、さくらインターネットが提供している「さくらのレンタルサーバ」の仕様とそっくりだった。
レンタルサーバー機能一覧：
http://server-cowboy.jp/function.html
SSHを提供してみたり、Cronも開放してみたり…と、「さくらのレンタルサーバ」が、ちょっと特徴的なサービスを踏襲しつつ、マルチドメインの数を無制限にしたりと小技も使っていたりする。
価格についても、肌感覚で一番売れているであろう「さくらのレンタルサーバ」のスタンダードに合わせている感じがなんとも…。(しかも、ドメインの取得費用についても、さくらの値段に合わせている気がするのは私だろうか…)
従来のファーストサーバのサービスラインナップからすると、結構安くて、充実したスペックになっている印象がある。まぁ、やればできるんじゃんなんて感想を持ってしまった。
ただまぁ、このファーストサーバのサービスリリースを眺めている限りでは、さくらインターネットがレンタルサーバの価格とスペックの「標準」になっているということだろうし、従来からのレンタルサーバのスペックを「押し上げて」、価格を「押し下げた」ということだろう。また、ファーストサーバくらいの規模であれば、さくらインターネットと同じレベルのサービスを提供しながらも、同じくらいの価格設定ができるということも明らかになった気がする。
ということは、さくらインターネットやファーストサーバほどの規模がない中小のレンタルサーバ事業者にとっては厳しい事業環境になるんだろうなぁ…。
えーと、うちのNASはBuffaloの「HS-DHGL」。
確か、2006年頃に発売された製品だったか。いわゆる、家庭向けのLinkStationで、DLNA機能とか付いているけれど、ほとんど使ったことはなく、純粋にNASとしてしか使っていない。購入以来、HDDが容量不足になったのでHDDを換装してあったり(今、1TBのHDDがささってたはず)、ファームウェアも書き換えてあって、iSCSIとかしゃべれたりするのだが、これまた使っていない(汗)telnetログインできるんだが、なんだかエラーを吐いてるのが見える（WebのGUIにアクセスした途端に、error.cgiがCPUを食い始める…という）ので精神衛生上よろしくないかもしれない。
一応、このLinkStationにはUSB-HDDを接続して、そこにNASの中身をバックアップを取っていたんだが、このUSB-HDDがたまに書き込み不良になって、NASから切り離されたりする…というわけで、そろそろリプレースするか、となんとなく思い始めている。
とはいえ、次もLinkStationでは芸がないので、Atomを使った箱を作って、そこに「FreeNAS」をインストールしてしまおうかと。FreeNASは、名前の通り、FreeBSDベースと言うことで、あこがれのZFS(…RAIDカードなしに、RAID6相当の冗長性を確保できるのはいいと思うんだけど）も使えるし、GUIも付いているので管理も楽そうだ。うちのWindows7マシンからはiSCSIでマウントすることもできそうだし、…なかなか興味深い。
とりあえず、HDDがごそっとささるAtom箱を作るところからかー。
久しぶりにmemcachedのサイトを見てみたら、新しい1.4.5がリリースされてたので、RPMを作ってサーバにインストールしようとしたら、rpmbuildでコケた。サーバはx86なマシンで、CentOSの5.3が動いてる感じ。
rpmbuildが異常終了した後、画面に出てる文字列を眺めてみる。
(前略)
t/item_size_max……ok
t/line-lengths…….ok
t/lru…………….ok
t/maxconns………..ok
t/multiversioning….ok
t/noreply…………ok
t/stats-detail…….ok
t/stats…………..ok
t/udp…………….ok
t/unixsocket………ok
t/whitespace………skipped
all skipped: Skipping tests probably because you don’t have git.
Failed Test Stat Wstat Total Fail Failed List of Failed
——————————————————————————-
t/binary.t 255 65280 3361 6212 184.83% 240 243-244 251 255 258-3361
2 tests skipped.
Failed 1/39 test scripts, 97.44% okay. 3109/6475 subtests failed, 51.98% okay.
make: *** [test] エラー 255
エラー: /var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)
RPM ビルドエラー:
/var/tmp/rpm-tmp.94575 の不正な終了ステータス (%check)
うーむ。さっぱりわからん(汗)
なんとなーく、ビルドの過程は終わっているんだけど、make testが走りきらない感じですかね。
何回やってもラチがあかないので、調べてみたら、この辺とか、この辺に、なんとなく関係がありそうなことが書いてあった。
妄想の域は出ないけれど、memcachedが依存しているモジュールのバージョンの問題なのかも。具体的には、memcachedの1.4.4まではlibeventの1.1でも動作するけれど、1.4.5からlibeventの1.1ではダメで、1.4あたりを必要とするのではないかと。で、CentOS 5.4以前のRPMレポジトリに入っているlibeventは1.1で、CentOS5.5(現時点でリリースされてるのは、RHEL5.5の方だけ)になったらlibeventが1.4あたりにバージョンアップされる…と。結局、memcached1.4.5をビルドしようと思ったら、CentOS5.5のリリースを待って、アップグレードをかけなきゃいけないってことなのかな。あー。
昨日、眠い目をこすりながら、書いた内容をぼんやりと反芻しつつ、追記。やっぱり、ASPもどきなアプリケーションベンダーさんのことはさておいて、いわゆるHaaS周辺のことを。
クラウドの中の1VM(以下、仮想サーバ)と、占有型レンタルサーバ1台(以下、物理サーバ)を比較してみると、結局、root権限付きのサーバが使えるというサービス内容にさしたる違いがあるわけでもなく、どっちでもいいじゃんという印象になる。仮想サーバには、すぐに調達出来て…とか、トラフィックに応じて従量課金で…とか、まぁ、いくつか特徴はあるんだろうが、それとて、いくつかは物理サーバを借りても実現不可能なことではないはずだ。また、余談ではあるが、クラウドEXPOにて、HaaSとして紹介されてた仮想サーバについて話を聞いてみると、お申し込みからX営業日以内には使えるようにしますので…ってレベルだった。それはレンタルサーバ屋で物理サーバを借りるのとリードタイムは変わらなかったりするわけで、AmazonのEC2くらいにシステム管理が自動化されていることが前提の話だろう。まぁ、ぱっと見た感じ、やっぱクラウドだよねぇと思えるようなサービスは見当たらなかったというのが正直な感想だ。
では、レン鯖じゃなくて、クラウドがいいよねぇと思えるのは、どんなサービスだろうか。ここで、あえて仮想サーバと物理サーバという表現を使わなかったのは、結局、既存の物理サーバの枠組みで、束ねられたリソースをそのまま仮想化して仮想サーバを用意したところで、それらの違いというか、クラウドの特長は見出しづらいと思うからだ。逆に言えば、クラウドというのは実態としては、物理サーバのリソースの束であり、それらをユーザに提供する際に、適切な「サービス」に分解して提供することになる。そのサービスの切り方というか、枠組みを工夫しないといけないんじゃないだろうか。そう考えると、物理サーバを束ねて、(また、同じ枠組みで切り直して)仮想サーバをサービスとして切り出すのは、ただ穴を掘ってただ埋める的というか、なんとなく無駄な営みに見えてくるのは私だけだろうか。
…と書いた時点で、リソースの束を物理サーバの枠組みでサービスを切り出すのがアレなわけだから、なんとなくクラウドがいいよねぇと思えるようなサービスのあり方のひとつは、AmazonのS3みたいな、リソースを機能で切り出したサービスなんだろうなぁとぼんやり思う。S3の場合、データの出し入れを実現するストレージとして存在しながらも、容量無制限の感覚で使えるというのは、物理サーバの制約(実際はOSの制約かな)というか、枠組みから自由になれるというメリットをユーザに提供するわけで、これはただレン鯖を並べてストレージとしての容量を確保するだけでは実現できない。
結局、Amazonを賞賛するだけになるのもアレだけど、良質なリソースを調達、保有するだけでは、売れるクラウドなサービスを作れないんだろうなと思う。例えば、「適切なサービスを設計しうるコンセプトやアーキテクチャを設計出来るか」とか「リソースを束ね、かつ、サービスに分解しうるソフトウェアを開発できるか」といった能力が決め手になりそうな気がする。そして、(個人的に、クラウドらしいサービスを提供しているような気がする)Amazonにしろ、Googleにしろ、端的に言えば、クラウドを内製する能力というか、自分達が必要とするものをきちっと自分たちで作り上げられる能力を持っていることと、クラウドらしいサービスを外に提供していることは、無縁ではないのかもしれない。
今のHaaSのような、仮想サーバのインスタンスを借りるようなサービスが使い辛いのは、既存のサーバ群との組み合わせがしづらいことだと思った。例えば、自社で保有するサーバ群を使いながら、HaaSを使おうとすると「Webレイヤーは自社で、DBはHaaSで」みたいなアーキテクチャだとやっぱり、WebとDB間のネットワーク的なレイテンシーが気になってしまう。その逆もアレだし、どこかにロードバランサを置いて、自社サーバのクラスタと、クラウドのクラスタに振るってのも強引というか、クラウドじゃなくて、レン鯖のクラスタでコトが足りるんじゃないかと思うし、最終的には移行するかしないかというオオゴトに発展してしまうのではないか。そういう意味では、スタートアップな人たちは、今のHaaSは使い易いんだろうなぁ。
一方、例えば、「データをどれだけ入れても、さくっと出てくる」のに「容量無制限」なストレージサービスだったり、嫌になるほど、膨大だったり、ややこしかったりする計算をぶん投げると、並列化して計算してさくっと返してくれるような計算機サービスがあれば、自社サーバ群が苦手で、クラウドが得意な処理を切り出して、クラウドに処理をぶん投げられて楽なんだけどなぁと妄想してしまうが、クラウドEXPOをうろついてみたけれど、これだってサービスは見当たらなかった気がする。既存のリソースを持ってる人たちが、クラウドのリソースと、割と疎結合でつながれるようなサービスってないなぁとも思った。
© 2024 ただのにっき。
Theme by Anders Noren — 上へ ↑