Cloudへの切り替えTweet2015/09/09この記事はAppknox社のフルスタック&DevOpsエンジニアであるdhilipsiva氏による寄稿です。モバイルアプリケーションのセキュリティホールの検知に役立っています。ストアのリンクを送信するだけで、アプリの安全性を確保できます。リンクを受け取ると、弊社は対象アプリをアップロードし、セキュリティ脆弱性をスキャンして結果を報告します。(※訳注:Appknoxとは..モバイルアプリを定期的に自動でスキャン・分析し、脆弱性が発見された場合に警告を出してくれる全自動のセキュリティ監視ツール『appknox』を提供しているインドで注目されているスタートアップの一つです。)弊社のスタックの特徴を以下に示します。フロントエンドとバックエンドを切り離すため、モジュール化を進めました。このアーキテクチャの多くの利点についてはこの記事の後半でお話しします。Cloudへの切り替えが簡単に実行できました。Storageアーキテクチャ動作の仕組みは?バックエンドアーキテクチャはクライアント、データおよびワーカーの3つのサブシステムで構成されています。クライアントサブシステムクライアントサブシステムは、2つの異なる負荷分散された自動スケーリングのアプリ&ソケットサーバで構成されています。ここでユーザとの相互作用が実行されます。遅延(レイテンシ)をできる限り低減するために、ブロッキング・コールがないよう細心の注意を払いました。アプリサーバ:各アプリサーバはNginxおよびDjango-gunicornサーバがロードされた単独の計算ユニットで、supervisordにより管理されています。ユーザからの要求はここで処理されます。ユーザがアプリのURLを送信すると、それをRabbitMQdownloadのキューに送信して、ただちにURLが送信されたことをユーザに通知します。アプリをアップロードする場合は、サーバから署名付きのURLが取得されます。ブラウザはこの署名付きURLと共にデータをS3へ直接アップロードして、完了するとアプリサーバにそれを通知します。ソケットサーバ:各ソケットサーバはNginxおよびノード(socket-io)サーバがロードされた単独の計算ユニットです。このサーバはアダプタとしてRedisを使用します。このサーバはリアルタイム更新のために使用されます。データサブシステムこのシステムはデータ格納、キューイングおよびPub-Subに使用されます。分離アーキテクチャも担当します。データベースクラスタ:Postgresを使っています。ご存知の通り、書き込み性能重視のマスターと数個の読み込み性能重視のレプリカで構成されています。RabbitMQ:celeryワーカーのブローカーです。異なるワーカーには異なる待ち行列があります。download、validate、upload、analyse、report、mailおよびbotです。ウェブサーバはデータを待ち行列に置き、celeryワーカーはそれを拾って実行します。Redis:これはsocket-ioサーバのアダプタとして動作します。ユーザにワーカーからの更新を通知したいときは、Redisに送信すると、Socket.IOを通してすべてのユーザに通知されます。ワーカーサブシステムここですべての力仕事が行われます。すべてのワーカーはRabbitMQからタスクを受け取り、Redisを介してユーザ宛に発行された更新を受け取ります。静的スキャナ:これは自動スケーリングの計算ユニットグループです。各ユニットは4から5のceleryワーカーで構成されています。各celeryワーカーは一度に1つのアプリをスキャンします。その他のタスク:これは自動スケーリングの計算ユニットグループです。各ユニットは、ストアからアプリのダウンロード、レポートのPDF生成、レポートPDFのアップロード、メールの送信など多様なタスクを実行する4から5のceleryワーカーで構成されています。動的スキャン:これはプラットフォーム固有になります。各Android向け動的スキャナはオンデマンドの計算インスタンスであり、Androidエミュレータ(SDK付き)とデータをキャプチャするスクリプトを備えています。このエミュレータはユーザが使用するためにブラウザのキャンバス上に表示されます。各iOSスキャナは管理されたMac-Miniファームであり、iOSプラットフォームをサポートするスクリプトとシミュレータを備えています。スタックの選択理由Pythonは、アプリをスキャンするために使用している主要ライブラリがpythonであるという理由で選びました。それに、知っている言語の中でpythonが一番大好きだからです。Djangoはモジュール方式を採用しているので選びました。世に出ているフロントエンドフレームワークの中で最高のものだと思っています。確かに学習の道は険しいですが、急勾配の山を一度登頂すると、誰でもemberを愛さずにはいられなくなるのです。その規約に忠実でいれば、最小限のコーディングで最大の効果が得られます。元々は、業界標準だったMySQLを選びました。Microsystems(MySQLの親会社)を買収した後、MySQLは停滞してしまいました。皆そうなるのではないかと予想していたとは思いますが。このため、コミュニティにより保守されていたMariaDB(MySQLの派生)を使い始めました。その後、必要としていた持続性のあるKey-ValueストアがPostgresによってそのまま使用できる形で提供されていることがわかりました。これはPythonとも相性が良いです。プライマリーキーとして使用しています。uuis-osspモジュールは、よりコストのかかるアプリケーションレベルでの作成ではなく、データベースレベルでUUIDを生成および操作する機能を提供していました。これらの理由により、弊社はPostgresに切り替えました。その他については業界標準のものを選びました。タスクのキューイングにはRabbitMQ。タスク管理にはCelery。Pub-SubにはRedis。想定通りに運ばなかった事柄の一つとしてソケットのスケーリングがあります。開始当時はDjango-socket.ioを使用していました。その後、これでは複数サーバにスケーリングできないことに気付きました。そこで、個別のnodeモジュールとしてコーディングしました。Redisアダプタをサポートしているnodeのsocket-ioライブラリを使用しました。クライアントはnodeのソケットサーバに接続されています。このため現在ではpythonコードからRedisに発行します。nodeはただクライアントに通知をプッシュ送信します。これで、クライアントにとってJSONエンドポイントの役割を担うアプリサーバに依存せずにスケーリングすることができます。スタックの特徴モジュール方式の設計が大好きです。フロントエンドとバックエンドを切り離すために、これまでの要素はモジュラー化してきました。読み間違いではありません。すべてのHTML、CoffeeScript、LESSコードがバックエンドに依存せずに開発されました。フロントエンド開発はサーバが稼働していなくても可能です。開発中のダミーデータとして、フロントエンドのテストデータ設定ファイルに頼っています。バックエンドをシャーロックと名付けました。私たちはモバイルアプリケーションのセキュリティ脆弱性を検出します。この名前がぴったりだと思いました。シャーロックは賢いですから。フロントエンドをアイリーンと名付けました。アイリーン・アドラーを覚えていますか?彼女は美しく、華やかで私たちのユーザに問題点を伝えます。最後に、管理系をハドソンと名付けました。シャーロックの大家さん、ハドソン夫人を覚えていますか?考えてみれば、かわいそうなワトソン博士にも何か役をあげればよかったですね。将来的にはそうするかもしれません。シャーロックはHTML/CSS/JSファイルを処理しません。HTMLファイルを1つも処理しません。シャーロックとアイリーンは両名とも個別に開発されました。両名とも個別の展開プロセスを備えています。両名ともに独自のテストケースがあります。格納のために展開します。このようなアーキテクチャの利点を以下に示します。フロントエンドチームとバックエンドチームがお互いの邪魔をせずに独立して作業できます。サーバ上でのページのレンダリングなどの重労働からサーバを解放できます。フロントエンドのコードをオープンソース化できます。フロントエンドのための人員を雇うのが簡単になります。repoツールに上がっているバグを修正しておいて、と依頼するだけで雇うことができます。ブランチから自動展開されます。ブランチモデルを採用しています。ブランチに注力します。masterブランチにマージすると、コードが自動的に展開されます。Cloudの使用を決めました。様々なアプリケーションのリソース管理に対する「プロジェクト」ベースのアプローチが気に入りました。これは、インフラへのアクセスをより実用的にします。弊社の「動的スキャン」機能の複雑性のためにインスタンスの識別が容易になりました。素晴らしいドキュメンテーションが備えられていて、困ったときにはGoogleエンジニアから個別の1対1サポートが受けられました。特典を付与され、初期段階からコストを削減する助けになりました。今まで弊社では、IaaSプロバイダの特殊なサービスは避けるようにしてきました。RDSやSQSは使用しませんでした。独自のDBサーバ、RabbitMQおよびRedisインスタンスを構成しました。その理由としては、それらのサービスは比較的遅く(そしてコストが高く)、自社の製品がベンダー依存になってしまうことが挙げられます。これらすべてをベンダー非依存にするために抽象化しました。ストレージを抽象化することを忘れていました。これまで弊社はS3を直接使っていました。Cloudに移行しようとしたときの小さな改善点になりました。Storageへの移行を決めたときは、ストレージレイヤを抽象化してGoogleのストレージ移行ドキュメントに従いました。すべてがうまく行きました。CloudとAWSの両方でコードの変更なしにホストできるようになりました。構成を変える必要は出てきますが、コードはそのままで使えます。原文:http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html(2015-5-25)※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。今夜が頑張り時のエンジニアのために。❏「フリ【比較表あり】非エンジニアの人にも知ってほしい。私がReact/Fluxアプリケーションを書いてきて、もう1年になる。