まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

「起動中の Amazon EC2 のインスタンスが消える!?」というオカルトな現象に2度ほど遭遇しました。

1度目はオペレーションミスか勘違いかと思ったんですが、2度あるとさすがに勘違いでは済まなくなります。

まあサーバーとしては実稼働中ではなかった(実はこれがクセモノだった、実稼働中ならもっと早く真相に気づけたかも)ので、深刻な状態にはならなかったのですが、この現象の正体を突き止めるべく調べてみました。


この怪現象はこんな感じ。Amazon EC2 にログインして、サーバーインスタンスを起動して使っていました(画面は管理コンソールです)。
2014010807


が、ある時に同じ管理コンソールを見てみると動いていたはずのインスタンスが消えています! まじかっ!?
2014010808


何がなんだかよく分からないけど、消えてしまったものはもう存在しないんだよね? それなら再度構成しないといけないのでインスタンスを作リ直して・・・ なんてやってました。

このインスタンスは本稼働前の準備段階のインスタンスだったので実際にユーザーがアクセスしたりしていたわけではないのです。その意味では「ああ本番前でよかった」と問題にはならなかったのですが、、 すごいオチが隠れてました。 みなさん、分かります?



以下、真相です。

まずサーバーインスタンスは消えたわけではなく、ちゃんとずっと動いていました。なので本来は作り直す必要もありませんでした。

ではなぜ管理コンソールから消えていたのか?

これは単に異なるリージョンを見ていた、ということでした。

上記図を再度見直してみます。最初のインスタンス稼働中の管理コンソール画面ではリージョンは US East(N.Virginia) に設定されていました。つまりこのサーバーはバージニア州のデータセンター内で動いていた、ということです。
2014010801

次にサーバーが消えたように見えた管理コンソール画面のリージョンは US West(Oregon) になっています。つまりこちらはオレゴン州のデータセンターを参照していて、そこでは(作ってないから当たり前ですが)何も動いていない、ということでした。
2014010804


そっかー。なんだ、リージョンが切り替わったのに気付かなかっただけか。 めでたし、めでたし。


・・・ところでいつリージョンが切り替わったんだ?俺は何もしてないぞ。 
管理コンソール見るたびにリージョンなんか意識してないし、こんなことが頻繁に起こってたら、いつか本当にやらかす可能性があるぞ。

で、このリージョン切り替わりの謎をずっと探っていたのですが、最近になってやっと分かりました。結論としては
 ・AWS のリージョン情報がブラウザのクッキーに残っていて、
 ・AWS アカウントを複数持っていて、適宜切り替えて使っていた
のが原因でした。

まず AWS のリージョン情報(らしきもの)はブラウザのクッキーに残っていました。console.aws.amazon.com のクッキーとして3つの(それぞれの用途はわかりませんが) "us-west-2" リージョンが記録されていることを確認しています。
2014010805


次に自分は業務用と個人用と、2つの AWS アカウントを持っています。同じPCの同じブラウザで、ログインユーザーを切り替えて使っています。

たとえば、まず業務用アカウントを使ってログインしているとします。この時は US-East リージョンにあるインスタンスを使っています。
2014010801


この状態でいったんログアウトします。リージョン情報はクッキーに残っているので、次回ログイン時のデフォルトリージョンは US-East になるはずです(なので同じ業務用アカウントでログインした時はこの続きの管理コンソール画面が表示されるはずです)。

ここで個人用アカウントに切り替えてログインします。リージョン情報がクッキーに残っていて、どうやらユーザーごとの制御はしていないようなので個人用アカウントでも US-East リージョンで管理コンソールが表示されます。
2014010802

この状態から新しくサーバーインスタンスをリージョン指定なしで作り、それが US-West リージョンで作成された場合(或いは US-East 以外のリージョンを指定して作成した場合)、当然ですがインスタンスは US-East リージョンではなく、US-West リージョン内に作成されます。そしてこのタイミングで管理コンソールのリージョンも US-West に切り替わります。実際にインスタンスを作成しなくても、このようなオペレーションが行われたと仮定して(手動で) US-West リージョンに切り替えておくと、この後の現象を再現できます。
2014010803

この状態で個人用アカウントはログアウトし、再度業務用アカウントでログインし直します。するとクッキーに残ったリージョンは US-West なので、業務用アカウントでは前回のログアウト直前まで US-East で作業していたにも関わらず、US-West の画面になります。リージョンが異なるので当然ですがそこには直前の画面にあった稼働中のサーバーインスタンスはありません(見えません)。 これが「消えていた」ように見えたわけです。
2014010804

これが世にも恐ろしい「Amazon EC2 のインスタンスが消えた!」現象の原因だったように推測しています。

AWS アカウントを複数持っている人は少ないのか、利用者はリージョンを固定して使っているのか、ググってもこの現象が発生している、という情報を見つけることができませんでした。

上のはあくまで推測にすぎないのですが、現にクッキーの状態も推測にあっていたので、あながち間違ってないのかな、と思ってます。





 

AWS(Amazon Web Services) から提供されているクラウドサービスのラインナップは数多くあります。個人的にはこれまで IaaS の EC2 に、EC2 を固定 IP アドレスで使う Elastic IP、そしてストレージサービスであり静的HTMLサーバーにも使える S3 を使う機会が多くありました。

データベースサービスである RDS に関しては、その存在は以前から知っていて、MySQL インスタンスをセットアップしてテスト的に利用したことはありました。が、この RDS のデータベースはデフォルトの文字コードが latin1 になっていて※、日本語データを扱うサービスとして使うにはその設定を(一般的には UTF-8 などに)変更する必要がありました。

※正確には character_set_server と character_set_database の設定値が latin1 になっています。

例えば普通のサーバー環境だったり EC2 環境であれば、MySQL のデータベースの文字コードは /etc/my.cnf を直接書き換えることで簡単に変更できます。MySQL インストール時の一連の作業の1つとして認識しているエンジニアも多いでしょうし、なので初期設定値は問題ではないと考える人も多いかもしれません。

ただ今回は Amazon RDS という特殊な環境です。EC2 と違って SSH で直接ログインして /etc/my.cnf を編集して・・ というわけにはいかない状況です。でも日本語データを扱う上では必須な変更です。さてどうするか?

Amazon RDS ではパラメータグループという概念でこの問題を解決しています。/etc/my.cnf を直接編集することは許されていませんが、このパラメータグループの中で利用する文字セットをあらかじめ(UTF-8 などに)指定した上で、データベース作成時にそのパラメータグループを使って作成する、という方法で UTF-8 のデータベースを利用することができるようになります。

しかし、このパラメータグループの作成や編集をするには、これまでは Amazon から無料提供されている Amazon RDS Command Line Toolkit というコマンドラインツールをダウンロード&導入(更に導入の前提として Java 実行環境が必要だったりする)して、このコマンドラインツールからコマンドを実行するしかありませんでした。

要は「RDS で日本語データを扱う」というただそれだけのことが、できないことはないけど色々面倒だったわけでした。


が、最近になって改めて RDS を使った時にこのコマンドラインツールを使わなくても日本語環境を整えることができるようになっていたことに気付きました(いつからだろ??)。設定ファイルを直接書き換えるような方法と比べるとまだちょっと面倒ではありますが、コマンドラインツールはもう必須ではなく、同様の処理がウェブのUIからも可能になっていました。

その設定方法と内容は以下の通りです。Amazon RDS のウェブコンソールから "Parameter Groups" を選択します。標準で "default-mysql.5.x" という名前のパラメータグループがありますが、これを使うと文字化けから逃れれられなくなります。そこで "Create DB Parameter Group" ボタンをクリックして新しい日本語用のパラメータグループを作成します(ここではパラメータグループの名前として "prod" と指定したとします)。

作成したパラメータグループの "Parameters" 以下にそのパラメータと設定内容が一覧で表示されますが、その中の character_set_database と character_set_server の値としてどちらにも utf8 を指定して保存します。これで UTF-8 用のパラメータグループが作成できました。
2014010501


そして今作成したパラメータグループを指定して新たにデータベースインスタンスを作成します。ウェブコンソールの Instances を選択後に "Launch DB Instance" をクリックして新規にデータベースインスタンスを作成します。
2014010502

DBの種類や名前、DBサイズなどを指定していった後の "Step 4: Additional Config" の段階になると、作成するデータベースインスタンスのパラメータグループを指定する箇所があります。ここで先程 utf8 を指定して作成したパラメータグループの名前(この例では "prod")をプルダウンから選択します。これで character_set_database と character_set_server の値が latin1 ではなく utf8 に設定されたデータベースインスタンスを作成するよう指定したことになります。後はこのまま進めてデータベースを作成します。
2014010503

こうして作成したデータベースインスタンスの文字セットを確認するとこのような感じになりました:
2014010504

なぜかまだ character_set_database の値はまだ latin1 のままですが、character_set_server の値は utf8 に変更できました。ここまで出来てしまえばこの状態から SQL コマンドで

> create database XXXX default character set utf8;

で新たに UTF-8 のデータベースを作成してしまえばいいだけのことです。

ちょっとまだ面倒な所はあるけど Amazon RDS で日本語データベースを作成するためだけに Java 環境を整えた上でコマンドラインツールを導入、という必要はなくなったように思えます。

Amazon RDS はバックアップ付きリレーショナルデータベースサーバーとして気軽に(条件次第では無料枠内でも)使えて便利だったのですが、この日本語環境の構築に難があった、という印象でした。いつの間にこのUIがウェブコンソールに付いたのか不明ですが、これなら利用上のハードルはかなり下がったかな。




ソフトウェアの種類の1つに「アバンダンウェア(abandonware)」と呼ばれるものがあります。abandon = 「捨てる、諦める」という意味ですが、聞いたことあるでしょうか?

Wikipedia によると、その定義は「著作権者が既に販売をやめたりサポートしていないソフトウェア、あるいは様々な理由により、誰が著作権者であるか不明なソフトウェア」とされています。

定義を簡単にするため、ここでは以下のような古いソフト全般を指しているものとします。
・もともとは商用ソフトウェアとして(著作権が明示的になった状態で)売られていて、
・現在は販売もサポートも終了している(場合によっては販売元会社そのものがなくなっている)ソフトウェアで、
・現在の著作権の扱いについて、特に明確になっていないもの※

※販売元会社が「このソフトウェアの著作権を放棄する」或いは「著作権は保持する」等の意思を明確にしている場合は当然その内容に従うのですが、それらがないまま(会社が無くなったり、サポートも終了したりして)誰に問い合わせればよいかわからなくなった状態のもの、という括りで考えてください。

で、そんなアバンダンウェアの著作権について調べてみました。まず結論として「アバンダンウェアにも著作権は存在します」。より正確には「アバンダンウェアに対する扱いが法的に明確になっていない以上は、通常の著作権と同じ扱いになる」のです。で、そのような点が明確になっている法律を持った国が存在していないため、たとえ持ち主となる会社が消滅していても著作権は残っている、ということになります。また特に何の規約もない以上は原則がそのまま適用されることになるのでその期間は「公表から50年間」になると思います(この辺り、違っていたら詳しい方に指摘していただけると嬉しいです)。 現実問題として、そのようなソフトウェアの著作権を無視するような行為があった時に誰かに訴えられるのか? という問題はありますが、それはまた別問題です。訴える人がいないから著作権は存在しない、という判断にはなりません。

というわけで、むかーしの古いソフトであっても、これを他人に譲渡したからといってそんな損失はないだろう、というようなソフトであっても、売って利益を得るではなく単に譲渡するだけであっても、勝手にコピーしたり譲渡したりする行為は著作権違反になります。


で、ここからが本題です。
そのような行為が著作権違反になることはわかりました。わかった上で「なんとかならないだろうか?」と言いたいのです。

もちろん積極的に著作権違反を推奨する意図はありません。そのような行為によって損害を被る人や企業があるとしたらやめるべきです(その場合はサポートを続けてよ、と言いたいけど)。あと一部には「オープンソース化してコミュニティに任せるべき」という声もありますが、私自身はそこまで主張するつもりもありません。

その一方で、今では入手できなくなったソフトウェア資産をなんとかして残したいという思いもあります。私個人が所有している PC-DOS や MS-DOS、OS/2 といった現在では入手が困難なオペレーティングシステムから始まって、それらの上で動作する商用/非商用アプリケーションやツール、ゲームなどの環境があります。一部は仮想ディスクにサルベージして、仮想環境内で動いていますが、一部はハードウェアを含めた実環境もあります。正直個人でこれを持ち続けることに不安と疑問を感じつつも、上記の理由から相手が個人だろうが団体だろうが販売元であろうが「譲渡したくてもできない」というジレンマを抱えています。


法的にも「そのケースでも絶対にNG」という明記がされているわけではなく、「何も書かれてないから著作権の原則を適用」という判断に基づくものなので、もう少し現実的な判断にならないものかなあ、と思ったのでした。

#ま、平たく言えば「寛大に、大目に見ていただけませんかね?」ということです、はい・・・





このページのトップヘ