Tag: GAE’

DAU-Crawler/3.0 Release

 - by Don

DAU/Crawler

本日、SiReFaSoのコアエンジンであるDAU-Crawler/3.0をリリースしました。

DAU-Crawler/2.0からの変更点としては以下の通りです。内部的な処理の変更がメインで、外見上や仕様上の違いはありません。

  • Python 2.5からPython 2.7へ移行
  • Kay FrameworkをPython 2.7のものに差し替え
  • データストアAPIをDBからNDBへ移行
  • backendの処理をBackendsからModulesへ移行
  • 画像処理ライブラリをpypngからPILへ差し替え
  • robots.txtの解釈に関するバグの修正

SiReFaSoへの適用

SiReFaSoはまだDAU-Crawler/3.0への差し替えはしていません。しばらく別サーバで試験運用をしてから差し替えようと思います。

差し替え時にはDAU-Crawler/2.0の時と同様、全てのデータを削除した上で再度登録し直す作業が必要となります。メンテナンスには相当の時間がかかるため、スケジュールが決まり次第Disc-2に告知する予定です。

更新の目的

特に仕様上の変更は無いのですが(バグフィックスはあるけど)、Googleさんに「いつまでもPython 2.5使ってんじゃねーよ*すぞ(意訳)」って言われたので、ついでに色々まとめて更新したのでした。

SoSiReMiは?

SoSiReMiも更新しないといけませんが、こちらはまだメドが立っていません。SiReFaSoが片付いたら手を付けようと思います。

絵日記の終わり

 - 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 追記

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

SoSiReMiの不調

 - by Don

昨日の11:00 – 16:00頃、SoSiReMiの一部のページが表示されていませんでした。原因はGoogle App Engineの無料APIリソースを消費し尽くしたことによるものです。本日も、これを書いている1:00頃、既に無料枠の70%近くを消費しており、昨日よりも早い時間にサイトが表示されなくなることが予想されます。

今後の予定

内部の設計に無駄が多いことは自覚しているので、設計を最適化してサイトを作り直すことを考えています。ただ、そう短期間では無理です(SiReFaSoの時は数ヶ月かかった…)。それまでの間は、時々サイトが表示されない状態が続くと思います。ご利用中のユーザ・ゴーストマスタの方々には大変ご不便をおかけしますが、ご理解の程宜しくお願いいたします。

新規登録直後でPV数が多いことによる一時的なものと信じたい…ですが、急いで何とかしたいところです。

追記

主にアクセス解析でリソースを消費しているのですが、上限まで達したらアクセス解析を非表示にすることで、継続利用が可能となりました。ダウンロードやネットワーク更新は問題なくできると思います。

メンテナンス前後のGAE料金表比較

 - by Don

リソース消費量

Before

billing-before

billing-before

これが先週の土曜日、SiReFaSoのメンテナンス直前のリソース消費量。Frontend/Backend Instance Hours はこれ以上増える見込みはないので問題無いですが、Datastore Read Operations が無料割り当て枠の7割超えでちょっと危ないです。

After

billing-after

billing-after

これが先週とほぼ同時刻の今日のリソース消費量。省エネの努力が実って目標の50%を大きく下回りました。

レスポンス速度

Before

response-before

response-before

一度開いたページはキャッシュされるので高速ですが、新規ページを開くにはおよそ1000msかかっています。

After

responce-after

responce-after

現状維持できれば御の字くらいに考えていましたが、新規ページの作成におよそ600ms前後で以前より高速化しています。

内部的な変更点

Datastore Read Operations を減らすには、Datastoreへのアクセスを減らすためにMemcacheによるキャシュを有効に利用する必要があります。以前はリクエストがあったページの情報だけをDatastoreから取り出していましたが、今は全データをMemcacheでキャッシュし、そこからリクエストに応じてgrep検索という邪道な仕様となっています。

アクセス数への依存を断ち切ることはできましたが、今は登録データ数に比例してリソースを消費する仕様です。伺かのゴーストの全体数から考えて、登録数が4桁になるようなことはないだろうという甘い予測に基いて設計されています。仮にそこまで登録数が増えるような時代が来たとすれば、きっとその頃にはSiReFaSoはその役目を終えていることでしょう。