スライド共有アプリをAzureに対応させた話

こんにちは。@ryuzeeです。最近アジャイル、クラウド、DevOpsの3点セットで仕事しています :-)

さて、自分のスライドはこちらのスライド公開サイトに公開しているのですが、これはオープンソースの自作アプリケーションです。

もともとはAWS専用だった(Amazon S3とAmazon SQSに依存)のですが、今回時間があったのでAzureに対応しました(ソースはこちら)。さきほどAzureに移行していまのところ普通に動いています。構成としては、ロードバランサー(Traffic Manager)とWebサーバ(Nginx + Docker)2台とDBサーバ(MySQL)2台です。

Azureに対応させること自体は特に難しくなかったのですが、AWSと両方使ってみていろいろ気づいたことがあるので整理しておきます。

項目	AWS	Azure
オブジェクトストレージ	Amazon S3を利用。仮想マシンを経由しないでファイルをアップロードするには、Signature v4のAPIを使ってフォームの項目を生成する。保存したオブジェクトをマネージメントコンソールから見ることができるのは楽	Azure Blob Serviceを利用。こちらも同様にSASを使ってワンタイムのポスト先URLを生成してあげればOK。ただし64MB以上のファイルをアップロードする場合はブロックに分割して送らないといけない点は面倒。ポータルからはオブジェクトを見ることができない(のは辛い)
キュー	Amazon SQSを利用。スライドの変換処理のために不可視タイムアウトを設定して同一ファイルの変換が走らないようにしている。キューに入っているメッセージをマネージメントコンソールから見えるのは良い	Azure Blob Queueを利用。こちらも不可視タイムアウトの設定が可能。Ruby SDKを使ったが、操作感はほぼAWSと変わらない感じ。ポータルからキューの中身が見えるといいのだが...
仮想マシン	Amazon EC2を利用。もともとAWSで動かしていたときはt2.smallで動かしていた。IAM Roleを使うとAPIのアクセスキーとシークレットキーをサーバに埋め込まなくてよいので安心	Virtual Machinesを利用。Standard D1(1コア/3.5GBメモリ)を利用。Azureの場合は仮想マシンを立ち上げる際にあらかじめストレージの性能なども仮想マシンの性能にあわせた形でパッケージングされている点がAWSと大きくことなる。だいたいいい感じの仮想マシンがほしい、という場合に分かりやすい。あと東日本と西日本にリージョンがあって、同じ日本なのに西日本の方が値段が2割くらい安い
RDBMS	Amazon RDSを利用。MySQL、PostgreSQL、Oracle、SQL Server、MariaDBなど多くのRDBMSがマネージドで提供されているのはやっぱり楽。フェイルオーバーの設定とか自分でやりたくないし。規模が大きければAuroraを使う手もある	AzureにはSQL Databaseがあるが、これはエンジンはSQL Serverということなのでちょっと困った。Azureの場合ClearDBという選択肢もあるようだが、ポータルからアクセスするとあまりにデザインの違うサイトに飛んで行ったりするので一抹の不安を覚える...
ロードバランサー	Amazon Elastic Loadbalancingを利用。まぁ特段言うことはない感じ	Traffic Managerを利用。エンドポイントのURLがスッキリした感じなのはいい(trafficmanager.net)
ポータル画面	AWSの場合はサービスによってインターフェイスがかなり違う。ずっと使っているので慣れてはいるが、オプションで指定できる項目も多いので初心者は最初引くかもしれない	Azureの圧勝。Azureの場合はどのサービスでもUIのインターフェイスが揃っている点はかなり楽だと思う。このあたりはガイドラインがしっかりしているんだろうと思う。他のWindows製品もみんなそうだし。ただメニューで製品名をクリックしても、その製品が何ができるのかはポータル上では分からない気がする...。ちなみに上のスクリーンショットは自分でカスタマイズしたもの。こういうの分かりやすい
ドキュメント	各種サービスやSDKでなんだかんだいってドキュメントが揃っている点は開発者としては楽。サンプルの量も豊富だし	特にAPI関連について、どこに何のドキュメントがあるのか分からない上に、機械翻訳されたドキュメントにたどり着いても原文みないと分からない。ここは改善してほしい。