AWS クラウドで構築するスマホアプリ バックエンド
- 1. AWS クラウドで構築する スマホアプリ バックエンド JAWS-UG 長野支部キックオフミーティング NSEG 第52回勉強会 GeekLab.Nagano
- 2. 自己紹介 @kaki_k
- 3. よく使う構成
- 4. 構成図 AWS Cloud Elastic Load Balancing Mobile Client Route 53 ロードバランサー ＋ SSL証明書 iOS/Android アプリ DNS アプリケーション サーバー Amazon EC2 Amazon S3 画像、音声、映像 Amazon RDS DBサーバー (MySQL) Amazon SESEmail Amazon SNS
- 5. AWSアカウント割合 cloudpack 50% 直アカウント 50% • cloudpackさん、直アカウントで半々。 • 対企業向けは cloudpackさんにお願いしてます。 （プロジェクトのクライアントが大企業さんの場合） • 定額見積り、24時間監視、構成起動、SSL証明書の手配／年更新まで をお願いできるのがメリット。
- 6. サーバー設計
- 7. • 予定がなくても、いつでもできるよう考慮しておく • 2台目以降へは rsync でプログラム領域をコピー スケールアウト Snapshot AMI EC2 Instance EC2 Instance １台目 ２台目 ・・・ 再起動あり 再起動なしで取れるが 止めた方が確実 rsync Auto Scaling ELB
- 8. • 2台目はクローンなので複製されるとまずいものを、外に出す - もちろん RDB 同じサーバー内にRDBをインストールしない Amazon RDSを利用する - セッション情報 これはフレームワークがRDBに出すのでOKだった - ログのディレクトリをプロジェクトの下に置かない - ユーザーがアップロードするバイナリーファイル（画像等） をサーバー内に保存しない Amazon S3を利用する • バッチ(cron) は、1台目でのみ走るようにする
- 10. Appサーバー Mobile Client iOS/Android アプリ Amazon EC2 Amazon S3 画像、音声、映像 Amazon RDS DBサーバー (MySQL) Amazon SESEmail AWS SDK for Python (boto) 普通に SMTPサーバー として指定 IPアドレス指定 量が少ない場合は GMail、Google Apps で済ませてしまう場合もあり
- 11. Appサーバーのインストール • 最初はインストール手順をRedmineのWikiに書いていたが • インストール手順書が書けるものは、コード化できる • Chef Soloを導入 Client chef-solo アプリケーション サーバー Amazon EC2 コーディング 検証 実行 knife solo prepare knife solo cook knife solo prepare knife solo cook
- 12. バックアップ
- 13. スナップショット AWS Cloud アプリケーション サーバー Amazon EC2 EBS Volume Snapshot AMI EC2 Instance
- 14. • cloudpackアカウント - 1日1回、２世代、AWSのスナップショット機能で取っ てくれる - cloudpackさんに泣きついて、スナップショットから インスタンスを起動してもらった経験あり • 直アカウント - バックアップの重要性は身に染みた - cloudpackさんと同じことをしたくて、Python boto のスクリプトをcronに仕込んだ
- 15. サーバー監視
- 16. • cloudpackアカウントのものは、Nagiosのメールが来る - 24時間監視は素晴らしい。 のメールも来る • 直アカウントのもの - 「サーバーが落ちてるんだけど」と、ある日突然言われる - ZABBIXでアラートメール - GUIベースなので導入は楽 - コードベースでGit管理する場合は、Nagiosの方がいいか も - 最初は簡単な Web監視から始める - 徐々に ZABBIX client を入れて監視中 or
- 17. ZABBIXによるサーバー監視
- 18. パフォーマンス監視
- 20. • New Relicの導入 - 指定ライブラリを読み込むため、２行程度挿入するだ け（Pythonの場合） • New Relicでできること - 時間がかかっているトランザクション(URL)一覧 - トランザクションのタイムライン（SQLの時間） - 発行されたSQLステートメントの一覧（回数、時間） のここが凄い
- 22. Transactions
- 23. Trace details
- 24. ログ保存
- 25. ログ保存の必要性 • セキュリティ基準で - ログの１年間保存を要求されている - もちろん、これだけならサーバ内でのスクリプトで退 避で済む • スケールイン - サーバ台数が減るということは、縮退したサーバのログ が失われる
- 26. EC2 各種ログ Fluentd Client アプリケーションサーバー ログ収集サーバー Fluentd Server EC2 S3 bucket Disk アクセスログの解析
- 27. Fluentd + ElasticSearch + Kibana アクセスログの可視化
- 28. まとめ
- 29. • AWSでのインフラは、段階として以下のように発展する - どう構築するか - どう運用するか（バックアップ、監視、ログ保存） • 自分はインフラエンジニアではないと思っているが、 インフラの知識は必要 - かつインフラで忙殺される • #nseg、#glnagano でインフラ勉強会があったら 参加したい • JAWS-UG 長野支部がないことは気になっていた （ここでも陸の孤島？）奔走された方々に感謝いたします
- 30. おわり