sgykfjsm.github.com

AWS BeanstalkでDockerをカスタムAMIで使う。

既知の通り、BeanstalkでDockerを使うことができるが、通常の使い方だとインスタンスが配備される度にDocker ImageをPull、BuildしてからRunする。初期配備時は問題ないが、スケールアウトの観点で見た場合、非常にもたつくことがある。また、Docker Imageが大きい(800MB以上ぐらい?)と、devicemapper errorでBuildに失敗することが多い(ような気がする)。単にBuildに失敗しただけであれば切り離せば良いが、複数台のうちいくつかがBuildに失敗しただけでは検知が難しく、そのまま生き残ってしまうとムダなコストが発生する。

上記のような認識でいたため、これまではBeanstalkでDockerを運用することにはあまり乗り気ではなかった。しかし、同僚からの意見で予めデプロイしておいたカスタムAMIを使うのはどうか、という意見があり、検証することにした。

なお、結論から言うと、ここで記した方法では実運用に耐えないと思う。アレコレがんばらないで、素直にAmazon EC2 Container ServiceがGAになるのを待ったほうが良い。

AnsibleでMySQLをインストールする。

AWSなんかを使ってると、イチからMySQLなどの基本的なミドルウェアをセットアップすることは減ってくる。そんな中、AnsibleでMySQLをインストールする事になったのだけど、意外と忘れてたりAnsibleで作業するのと手作業で進めることの差異でちょっと詰まったりしたので、ここに備忘しておく。

Beanstalk管理下のインスタンスを安全に再起動する

現在のBeanstalkでインスタンスが再起動する場合は主に以下の3つがある。

  • アプリケーションをデプロイするとき
  • Configuration(JVMのパラメータとか)をデプロイするとき
  • Management ConsoleなどでRestart Appsを実行した時

しかし、運用の中では特定のインスタンスのみを再起動したい場合がある。また、再起動を行う場合、インスタンスを再起動すると自動的にTerminateしてしまうし、インスタンス内部のアプリケーションサーバを再起動すると、ELBからリクエストが来てしまう。ここではこういった点を考慮した安全な再起動の手順を確認する。

起動に失敗したインスタンスを調査する例

先日、とあるサービスで利用しているBeanstalk環境でインスタンスが起動に失敗した。ログを見ると、S3からリソースの取得に失敗していたようだ。
ネットワーク接続の状態としては、AWS内のネットワークでは疎通可能だが、インターネットを経由した通信は不可、という状況。具体的には、例えばAWSのインスタンスからはsshログイン可能だが、グローバルからのsshログインはできないといったような感じ。色々調べたけど、不意に調査対象のインスタンスがTerminateしてしまい、結局原因がわからないままになってしまった。

調査はAWS Supportとやりとりしながら行ったのだけれども、色々と情報収集を都度指示されて捗らなかった。
なので、ここには次また事象が再発した場合に備えて、障害発生時に取得しておきべきこと、確認すべきことを整理する。

Play!のDB設定について

自分が開発したわけでもないのだけれど、APIのパフォーマンスをどうにかしろ、チューニングしろと言われた。チューニング対象のAPIはPlay!を利用しており、DBのI/Oにパフォーマンスが強く依存するので、まずはDB周りのパラメータをしらべて改善していくことにした。

markdownをプレビューする

Macではプレビュー機能があるけど、markdownだとレンダリングされずにそのままが表示される。 ので、ちゃんとレンダリングされた状態でプレビューできるようにする。また、いつもvimを使って作業しているので、コマンドラインからプレビューできるようにする。

ただ、今回はlynxを使ってプレビューするので、あまり一般的なやり方ではないと思う。