Category:Web’

SoSiReMi障害情報

 - by Don

2013-02-03 17:00現在までにかけてSoSiReMiサモンナイツ・クインテットにおいてネットワーク更新が正常に行われていない状態が確認されました。

原因はNARアップロード時に内部でネットワーク更新用ファイルの作成を行う際、処理が失敗したことによるものです。

連続した更新問い合わせによる負荷の増大が懸念されたため、管理者権限でNARの削除・新規アップロードを行い、原状回復を致しました。それに伴い、過去のダウンロード回数やネットワーク更新回数等のログは破棄されました。

ご利用中のゴーストマスタ並びにユーザの皆様には度々ご不便をお掛けしてしまい申し訳ありません。不安定なアップローダーで恐縮ですが、温かい目で見守って頂ければ幸いです。

最近SoSiReMiの障害情報ブログみたくなってきましたね。

絵日記の終わり

 - by Don

びーふれんずの日記投稿機能はland.toサーバを経由していたのですが、今日Google App Engineの方に移植して引き上げてきました。それに伴い、移植が困難であると判断したため、デスクトップのスクリーンショットを投稿する「絵日記」機能を廃止しました。また、投稿先はTwitterはてなハイクの2箇所のみとなります。

land.toに置いていたBOTはこれで全部引き上げたはずです。今の場所もいつまで続くかわかりませんが、長く続くといいですね。

SoSiReMiを少し最適化

 - by Don

SoSiReMiを一から作り直している傍ら、現状のものもアクセス解析の部分は少しの手間で改善できる気がしたので、改善してみた結果がこちら。

22:00時点で80%くらいなので、以前よりはマシですが1日持たない感じです。まあ、アクセス解析見れなくてもそんなに困らないですが…。

それよりも、その下の転送量がまだ10%にも満たないところに注目です。ご利用中のゴーストマスタ様方から容量削減にご協力頂いたことにより、SoSiReMiはもうしばらく生き長らえることができそうです。本当にありがとうございました。

これに甘えず、本格的な最適化に向けて準備を進めたいと思います。

ドスドス

 - by Don

今日はまた随分早い時間にSoSiReMiが落ちております。DL数はさすがに落ち着いているはずで、こういう時はまず攻撃を疑うものです。ログを見てみると大変わかりやすいDoS攻撃が確認できました。

dos

サイズの大きいNARに狙いを定めているあたりが効果的ですね。

対策

Google App EngineにはDoS Protection Serviceという機能が標準で利用できますので、早速試してみます。Pythonの場合はdos.yamlというファイルをルートに入れて、デプロイするだけです。書式はこんな感じです。

blacklist:- subnet: 1.2.3.4
  description: a single IP address
- subnet: 1.2.3.4/24
  description: an IPv4 subnet
- subnet: abcd::123:4567
  description: an IPv6 address
- subnet: abcd::123:4567/48
  description: an IPv6 subnet

とりあえずこれで様子を見ることにします。

お勉強ついでに

DoSというと一般にはトラフィック増大を引き起こして対象をサービス停止に追い込むものですが、クラウドサービスに対するものはEDoS(Economic Denial Of Service)と呼んだりするそうです。クラウドサービスは基本的にスケールが売りなのでDoS攻撃程度で落ちたりしないものですが、サービス体系が一般的に従量課金ですので、運営者に経済的な打撃を与えることが可能になります。ウチは無料枠超えたら現在のように落としてもらっているので大丈夫ですが、上限を定めていない青天井の契約形態のサービスは怖くて利用できないですね。

参考

SoSiReMiの分析

 - by Don

2012-10-01 10:09 – 16:00 の間、SoSiReMiが落ちていました。ご利用中の方々には大変ご不便をお掛けしました。

原因は先月も予想していましたが、新規公開ゴーストのダウンロード数が跳ね上がったことによる転送量オーバーです。1GB/dayまでの転送量が許されていますが、6.7MBのNARであれば160回ダウンロードされると余裕で1GBを超える計算になります。

quota analysis of sosiremi

上の100%になってしまっている方はアクセス解析のカウントを司るAPIです。これが上限を超えた場合でもアクセス解析を非表示化して何とか運用を続けています。その下のもうすぐ100%になりそうな方が転送量です。2012-10-01 23:00現在のものなので、もうすぐまた落ちます…。23:30追記:落ちました。

対策

SiReFaSoは巡回間隔を空けることで現状はなんとかなりそうですが、SoSiReMiはこのままではマズイですね。外部ストレージを活用するなどして全面的に作り直さないといけません。管理人が膝に矢を受けてしまったため作業が停滞しておりますが、回復までしばらくお待ち下さい…。

補足

SiReFaSoの時も気を回して頂いた方がいらっしゃいましたが、決して「使うな」と言ってるわけではないので早合点なさらないようお願いします。ご利用中または今後ご利用をお考えのゴーストマスタ様でご協力頂けることがあるとすれば、表情差分のみで構成された立ち絵のシェルに関してはelement合成によってNARの容量削減が見込めるため、転送量の削減に効果があります。SoSiReMiと地球にやさしいNARになりますので、ご検討頂けると助かります。

SiReFaSoの巡回間隔の変更

 - by Don

本日、以下のサイトにてメンテナンスを行いました。

内容は先週お知らせした通り、Google App Engineからの催促に応えたものです。

HRDに移行後もこれまで通りの動作を確認しましたが、1つ不都合が生じました。

リソース消費量の増加

以下の画像は20:30現在におけるSiReFaSoのリソース消費量です。

HRD

16:00にリセットされるので、4時間半経過した時点でDatastore Read Operationsという項目が3分の1消費されていることになります。これはSiReFaSoの設計において、登録時や巡回時にデータを更新する時に消費される項目なのですが、このままいけば明日の16:00まで持たないと考えられます。リソース消費量が100%になると、サイトがダウンして閲覧できなくなります(これまでにも何度か登録や更新が多い日にダウンしましたが)。

9:00追記

朝起きたらこんな感じでした。

hrd2

今日は16:00まで巡回はストップしておきます。

対策

リソース消費量削減のため、SiReFaSoの巡回間隔を、「1時間に1回」から「2時間に1回」に変更しました。もっとリソースを節約した設計を考えるべきところですが、前回の大幅な設計変更の際に既にかなりの節約を達成しており、これ以上は乾いた雑巾を絞るに等しい状態です。当面はこの巡回間隔で様子を見ながら、他の対策を考えることにします。

補足

1回の更新(巡回)で5~6%程度の消費を確認しています。最低でも24回+新規登録・更新用に数回=計30回分くらいは確保したい→1回の更新で3%の消費を目指す必要があります(HRDに移行する前はこのくらいだったんですけど)。かなり難題です。

またSoSiReMiとMiDoLaSoにも同じ影響がありますが、元々のリソース消費量があまり多くないのでまだ対策を打つほどではありません。でもSoSiReMiの場合は新規公開時にダウンロード数が跳ね上がるのでそれで落ちることがあるかもしれません。

メンテナンスのお知らせ(SiReFaSo,SoSiReMi,MiDoLaSo)

 - by Don

一昨日届いていたGoogle App Engineからのメールに気付きまして、「お前が使ってる昔のアプリケーション(Master/Slave datastore)は古いからもう使えなくなる。新しいの(High Replication Datastore)に移行しろ。(意訳)」という内容だったので、移行しないといけません。こうなることはわかっていたのですけれども今まで使っていたIDをそのまま継続使用できないのが不満だったので、その辺の対応が改善されるまでゴネていようと思ったのですが、年貢の納め時となってしまいました。

というわけで、来週末に以下のサイトでメンテナンスを行います。

2012-09-01 15:00:00 開始を予定しています(変更の可能性もあります)。完了までに数時間はかかると思われます。3つのサイトで一斉に行います(無謀)。

メンテナンスの間は上記サイトが利用できませんのでご了承をお願いいたします。

参考にするつもりのサイト

Master/Slave から HRD への移行 – キャラボット設定の参考になればいいなログ

2012-09-01 追記

メンテナンス完了しました。これまで通り、問題なくご利用頂けます。

SiReFaSoの登録情報を更新する

 - by Don

SiReFaSoに登録された情報を更新したい場合、SiReFaSoManagerを使う必要はありません。既に登録済みの情報を更新しようとしてSiReFaSoManagerで再登録しようとすると、homeurlやdirectoryの変更でない限りはエラーとなります(homeurlやdirectoryの情報も、SiReFaSoManagerを使わずに変更できます)。このあたりの仕様で誤解されることが多いので、登録情報を変更したい場合の方法をまとめてみました。

配布サイトURLを変更したい

descript.txtのcraftmanurlを変更してネットワーク更新します。

craftmanurl,http://new.example.com/

SiReFaSoの巡回により自動的にデータが更新されます。

ゴースト名や作者名を変更したい

上記と同様、descript.txtのnameやcraftman,craftmanwなどを変更してネットワーク更新します。

name,新ポスト
craftman,your-name
craftmanw,お名前

SiReFaSoの巡回により自動的にデータが更新されます。

プレビュー画像(ゴーストの立ち絵)を更新したい

surface0.png、surface10.png(バルーンの場合はballoons0.png、balloonk0.png)、それぞれに対応するPNAファイル、シェル(バルーン)のdescript.txt(use_self_alphaのチェック用)などを変更してネットワーク更新します。

SiReFaSoの巡回により自動的にデータが更新されます。

ディレクトリ名を変更したい

install.txtのdirectoryを変更してネットワーク更新します。

materiaやCROWでupdates2.dauを作成している場合、install.txtをネットワーク更新に含めることができません。SSPで作成するか、ゴースト配布系自動化システムをお使い下さい。

directory,new-directory

SiReFaSoの巡回により自動的にデータが更新されます。

以前のディレクトリ名でSiReFaSoにアクセスした場合でも、新しいディレクトリ名にリダイレクトされます。

例:

homeurlを変更したい

homeurlの変更に限らないですが、サイトの移転をする場合は.htaccessによるリダイレクトを設定します。

以下のような内容のテキストファイル(文末には改行必須)を作成し、名前を".htaccess"として保存し、FTPクライアントで以前のサイトのトップディレクトリにアップロードします(レンタルサーバーによっては.htaccessが利用できない場合があります)。

Redirect permanent / http://new.example.com/

これで旧URLにWebブラウザでアクセスすると、自動的に新URLに転送されます。

Webブラウザのみならず、Google先生も新URLを移転先とみなして検索結果に反映するようになります。サイト名で検索した時に旧URLがいつまでも上位に表示されるような状況を回避できます。

SSPでネットワーク更新した場合もリダイレクトを検出して新URLの更新ファイルを取得しに行きます。旧サイトの更新ファイルを使ってhomeurlを書き換え、次に新サイトの更新ファイルにより最新の状態になる、という2回のステップを踏む必要もなくなり、homeurl変更のための手間も省ける他、ユーザに対しても大変親切です。

SiReFaSoもこの方式(301リダイレクト)でのリダイレクトを検出した場合、移転とみなしてhomeurlの書き換えを行い、以降の巡回では新URLを使用するようにしています。

このサイトも以前に引越しを経験しております。旧URLからは301リダイレクトにより転送しています。

参照:cloudControlからPHP Fogへの移行 | すくりや

SiReFaSo自身も移転を経験しております。旧URLからは301リダイレクトにより転送しています。

参照:サイト移転時のリダイレクト関連のメモ

登録データを抹消したい

install.txtに"robots,noindex"を追記してネットワーク更新します(SiReFaSoの独自仕様)。

install.txtをネットワーク更新に含める方法についてはdirectoryの変更で説明した通り、ゴースト配布系自動化システムの利用を推奨します。

robots,noindex

SiReFaSoの巡回により直ちにデータが抹消されます。SiReFaSoManagerによる登録も、この記述がある限りは無効になります。

その他

既に登録したデータも、MD5不一致エラーやupdates2.dauに含まれたデータの誤削除(install.txt等)による404エラーの状態が1週間続くと自動的に削除されます。こうした事態を防ぐためにもゴースト配布系自動化システムの利用を推奨します。

DokuWikiを使ってみる

 - by Don

情報を書き溜めておくならブログよりもWikiの方が良さそうです。

自分のコントロール下に情報を置いておきたい場合は自分で設置するしかないなと思って色々試してみました。

日本語でそこそこ使えるWiki

試したのは以下の3つです。

PukiWiki

みんな大好きPukiWiki。伺か関連のサイトとしては駄でべWiki里々Wiki文屋など。大人気です。

PHP製。データベース不要。日本製。

そこそこシンプルな作りが魅力的ではあるけれど、最終更新が2006年ってかなり不安です。

MediaWiki

Wikipediaで使われているWikiエンジンです。超重量級。後ろ盾が確かな分、バージョンアップやバグフィックスも盛んです。

PHP製。データベースが別途必要。リソースは英語ベース、日本語のリソースも充実。

PHP Fogでデフォルトで用意されているので使ってみたけれど、最初のカスタマイズで疲れ果てました。何故か画像のアップロードでサムネイルが作成されないエラーが。サムネイルとか要らない…オプションで無効化できないの…疲れた…。

DokuWiki

名前は聞いたことがあったけど、使ったことはなかったので試してみました。

PHP製。データベース不要。リソースは英語ベース、日本語のリソースもまずまず。

超シンプル。インストール後の設定もURLの正規化くらいであとはデフォルトで十分使えるレベル。ストレスフルなまでのユーザビリティの低さ加減を除けは全く不満はないです。あまりのストレスに耐え切れずテンプレートを探してみましたが輪をかけて使いづらいものがザクザク引っかかりました。唯一まともだと思ったのがarctic-mbo Templateです。大変気に入りました。しばらくこれで使っていこうと思います。

PHP Fogに設置してみた

PHP Fogはフリーでアプリケーションが3つ作れます。此処のWordPressの他にあと2つ残っているのでDokuWiki用に1つ作ってみました。

たいして書き溜めておくようなこともないですが、自分専用ということでまずは運用してみます。

SparkleShareでGitoriousをDropBoxとして使う

 - by Don

前書き

land.toがいつも通りすぎて困ったということで、引越しを検討されているゴーストマスタさんが多いようです。DropBoxがゴーストの更新に便利ということで利用されているゴーストマスタさんもいらっしゃいますが、SiReFaSoで更新時刻が取得できないために断念されるケースもあるようです。

DropBoxは大変便利なツールですし、便利なツールはどんどん使われていってほしいのですが、場末のサイトがその利用促進を妨げていると思うと心苦しいので、代替案を探しておりました。

以下、ゴーストの更新時刻が取得できる版「オレオレDropBox」の作り方について解説します。

前提

以下のツールおよびWebサービスを使用します。無料です。

SparkleShare
オレオレDropbox製造機。WindowsのサポートバージョンはVista/7のみです。Windows XPはサポート外です。
Gitorious
色んなプログラムのソースコードなどが置いてあるサイトです。今回はオレオレDropbox置き場として使用します。

準備

基本的には上記サイトの説明通りに進めます。サーバーにGitHubを利用する場合と、自前で用意する場合について説明がありますが、今回はGitoriousを使ってみたいと思います。(GitHubはファイルの更新時刻が取得できないためです)

1. SparkleShareのダウンロード・セットアップ

最新のWindows用インストーラをダウンロードし、実行します。

SparkleShare-01

名前とEmailアドレスを入力します。(後でGitoriousのアカウントを取得するので、それと同じにすると良いです)

SparkleShare-02

説明が流れた後、インストールが終了します。

ここで、 C:Users<pc-username>SparkleShare<username>’s link code.txt というファイルが作成されます。これは後でGitoriousアカウントを取得した後の設定で使用します。

2. Gitoriousのアカウント取得・セットアップ

Gitoriousでアカウントを作成します。

送られてきたメールのリンクを踏むとアクティベーションが完了します。

Gitorious-01

"Manage SSH keys" というボタンをクリックします。

Gitorious-02

"Add SSH key" というボタンをクリックします。

Gitorious-04

ここに先ほど作成された <username>’s link code.txt の中身をコピペで貼り付けます。

Gitorious-05

続いて "Create a new project" というボタンをクリックします。

Gitorious-06

プロジェクト名やライセンスなどを設定します。私は ukagaka-apps という名前のプロジェクト名にしました。ライセンスは、迷ったらMITライセンスあたりがいいかと思います。

Gitorious-07

次に Add Repository のボタンからリポジトリ作成画面へ移動します。リポジトリ名は、ゴーストの更新ファイルを置くためのフォルダ名と思って構いません。私はプラグインのディレクトリ名のまま updater_yaya としました。

Gitorious-08

ここまででGitoriousの設定は終わりです。お疲れ様でした。

3. SparkleShareの再設定

SparkleShare-03

SparkleShareのメニューから Add hosted project を選択します。

SparkleShare-04

Gitoriousを選択し、Gitoriousで設定したプロジェクト名、リポジトリ名のパスを入力します。

SparkleShare-05

これですべての設定が完了です。お疲れ様でした。

SparkleShareフォルダの中にリポジトリ名のフォルダができています。 SparkleShare.txt というファイルがありますが、削除して構いません。ここにdescript.txtやらupdates2.dauやら、ゴーストの更新ファイル一式をコピーすれば、自動で同期が始まります。

4. ゴーストの更新URLの設定

肝心のゴーストのhomeurlを設定しましょう。ゴーストであれば辞書にhomeurlを設定する箇所があると思います。私の場合はPluginなので、descript.txtに記述します。

homeurl-01

homeurl は https://gitorious.org/<project-name>/<repository-name>/blobs/raw/master/ です。ここに最新の状態が反映されます。

まとめ

DropBoxとは違いますが、ゴーストの更新時刻が取得できる版「オレオレDropBox」の作り方でした。注意すべき点は、上記で説明したアプリやサービスの利用はすべて自己責任であることです。SparkleShareはまだ安定版ではないようですし、Gitoriousの利用規約には 500 MB/month 超えの転送量が確認されたら是正措置とるまで使えなくするよ的なことも書かれているようです。英語なので読みにくいですが、一読しておきましょう。