株式会社ダンゴネット　開発部のブログ - 仲介名人

ドメインのお話

開発本部の佐藤です。

2回目にしてネタに困り間が開いてしまいました汗

仲介名人の導入時ですが、それまで自社でホームページの運用をされていて、自社のドメインで仲介名人サイトが見れるような形に導入していただくケースが多々あります。

ドメインの仕組みというものはなかなか解りづらい部分がありますので、この機会にまとめてみようと思います。ドメイン取得に興味のある方はぜひご一読ください。

■独自ドメインとサブドメインについて

独自のドメインを取得しない場合、仲介名人サイトのheyaweb.comというドメインがご利用できます。
この場合では、お客さまごとに、http://○○○○.heyaweb.com/　というアドレスで自社のサイトにアクセスできるようになります。この形式を「サブドメイン」と呼びます。

サブドメイン形式ではドメイン取得の費用がかからないことがメリットですが、反面、独自ドメインに比べて検索エンジンにひっかかりにくいとも言われています。検索エンジンのアルゴリズムは日々変化していますので、ある日サブドメインが軽視されるようにならないとも限りません。

ちなみに、現在仲介名人をご利用いただいているお客様の比率では、ほとんど半々くらいです。

■独自ドメインを取得されている場合

現在ドメインをお持ちの場合は、そのドメインに対してどこのサーバが指定されているか、という情報を変更しなければいけません。
その指定をすることで、取得されているドメインに対し、弊社に設置されている仲介名人サーバとの紐付けができることになります。

この情報は誰でも好き勝手に変更できるわけではありませんので、ドメインを契約されているお客様に設定をしていただくことになります。
（が、弊社が代理で作業させていただくケースがほとんど、です。）

中にはその情報自体、変更できないドメイン管理会社様もいらっしゃいますので、その場合は自由に設定できるドメイン管理会社に管理先を変更する必要があります。ドメインと一緒に、ホームページのスペース・メール等のサービスがセットになっているような大手の業者では、このようなケースが多いようです。

この作業を、業界では「ドメイン移管」「レジストラ変更」などと呼んでいるようです。

逆に、ドメイン管理会社を変更することなく作業できる場合では、そのドメイン管理会社の方法に沿って、弊社で設定をしています。
web上から変更作業ができる業者もありますし、設定書を提出する必要が業者もありますが、最終的にはドメインと弊社サーバとの紐付けができる状態になります。

このような、ドメイン管理会社の変更なしに設定変更することを、「ドメイン振替」「DNS振替」などと呼んでいます。ういう用語は業者によって呼び方が違う場合が多く、いきなりでは意味が通じないことがあるので困りますね。。

このような作業を経て、仲介名人のサービスを導入いただいております。

次回は仲介名人のサービスの中身をご紹介したいと思います。

更新日時 ： 2008年03月27日 | この記事へのリンク ： 

仲介名人　メンテナンス舞台裏

開発本部の佐藤です。

今日は仲介名人立ち上げ後、はじめてのサイト休止してのメンテナンスがありましたので、その周辺を書いてみたいと思います。

まず、何故今回に限ってサイト休止になったかということですが、今回までのアップデートはモジュール部分（サイト本体）の更新が主であって、大量に更新が必要な、データベース内の物件データすべてに関わる変更は行われていませんでした。

物件データ（○万件）すべて更新しなくてはいけないとなるとやはり相当の時間がかかってしまうわけで、その間アクセスできなくなってしまうため、1時間ほどメンテナンス期間を設けることにしました。

メンテナンスと聞くと楽に見えますが、なかなか大変です。

まず、サイトのメンテナンス告知を行う表示をどうするか。

現在の仲介名人では、管理画面からメンテナンスモードへの切り替えができますが、今回のようにデータベースまで止めてしまう場合ですと、対応できません。（データベースへ値を見に行くことすらできませんので）

なので、apacheへ来たリクエストをすべて静的HTMLへredirectしてしまうことにしました。

（ここからマニアックになりますが・・・）

apacheのmod_rewriteというURL変換機能を使います。

   RewriteRule mainte\.html$ -      [L]
   RewriteRule ^.* http://www.heyaweb.com/www/mainte.html [L,R=302]

これですべてのアクセスがメンテナンス画面へ移動できました。（R=302でリソースの一時的な移転を通知したのですが、後で調べたらapacheでリダイレクトするとデフォルトで302が行くらしいので今から思うと無くても別によかったですが）

そしてメインのDBサーバのアップデート。

用意してあったアップデート用のクエリを発行すると、案の定エラーがでます。

これは焦ります。

	ERROR:  kind mismatch between backends
	HINT:  check data consistency between master and secondary
	server closed the connection unexpectedly
        	This probably means the server terminated abnormally
        	before or while processing the request.
		connection to server was lost

レプリケーション（複製）をしているデータベース同士の整合性がとれていなかったみたいです。

テスト用サーバは1台ですので、その環境の違いが出てしまいました。

いろいろ原因を調べて（ここで45分/1時間ほど）、テーブルを修正後、無事アップデート開始。

処理自体に20分ほどかかってしまい、結局予定の時間を10分ほどオーバーしてサービス再開に至りました。

こんな形で日々勉強しながら運営しております。

更新日時 ： 2007年12月12日 | この記事へのリンク ：