第六章 函数 6.1 概述 6.2 函数定义的一般形式 6.3 函数参数和函数返回值 6.4 函数的调用 6.5 函数的嵌套调用 6.6 函数的递归调用 6.7 数组作为函数的参数
「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜
-
Upload
interu07 -
Category
Technology
-
view
7.825 -
download
1
description
Transcript of 「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜
AWSを活用して少人数で複数のサービスを運用するコツ
株式会社 ソニックガーデン安達 輝雄
自己紹介
開発しているサービス
@interu 安達輝雄
アプリケーションの開発+
インフラの構築/運用
http://interu.hatenablog.com
SonicGarden
エンジニア:5名
開発/運用サービス一覧自社サービス
パートナーシップモデル
・データ販売サイト・ドキュメント配信・Flash動画生成サービス
・植物栽培キッド販売サイト・SEO関連サービス ・・・etc
いくつものサービスを
たった5人のエンジニアでどうやって
開発 / 運用 してる?
Answer.
DevOpsand
AWS/Herokuand
自動化/共通化/効率化
:5 : 5
利用比率
今日はJAWS-UG。
Herokuの話はすべて割愛!
そろそろ本題に
SonicGardenはサービス運用について
どのように考えているか?
SonicGardenのMission
開発 > 運用
SonicGarden流サービス運用ポリシー
構築/運用コストは抑えつつ安定したサービスを提供する
運用コストをどのように抑える?
構築/運用コストを抑える
航空業界の
LCC的発想
構築/運用コストを抑える
● 機体を1つのシリーズに統一● 研修/教育コストを抑えれる● パイロットなら誰でも運転できる
※ 機体毎に免許取得が義務付けられている
● システムの自動化● チェックイン等を全てシステム化● 通常フローで人を介すサービスをしない
LCC
構築/運用コストを抑える
● OS/ディストロを統一
SonicGarden
- ミドルウェア導入/設定- セキュリティ設定など基本設定を行ったテンプレートAMIを作成し、アプリのみを入れ替えてサービス
構築/運用コストの削減
安定したサービスの提供
● システムの自動化
SonicGarden
- EBSスナップショットの取得- 実データをS3にバックアップ- AMIの定期作成 ...etc
安定した品質を全サービスで提供
LCC的発想以外にも...
新しいディストロの採用
● 新しいパッケージを利用可能● アプリケーションF/Wに追従しやすい
● パッケージがメンテされている● Security Fix / Bug Fixをすぐに適用できる
運用コストを削減
2年で全乗り換え
ディストロの置き換えは大変では?
Railsのバージョンアップに伴いAPサーバを新しいディストロに切り替え
Ruby 1.8.7 ⇛ 1.9.3
リプレースまでの過程
(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
EBSの活用
EC2の活用
リプレースまでの過程
(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
リプレースまでの過程
(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替えELB/Route53/Elastic IPの活用
その他、効率化を目的に
いくつか取り組んでいることを紹介
① バックアップ
① バックアップ
データ/ログのバックアップを取得するのは当たりまえ
バックアップ処理中のエラー検出も当たりまえ
① バックアップ
本当にバックアップを取得できてる??
① バックアップバックアップしたものが
存在するかを確認する方が確実
だけど・・・複数サービスを運用していると
全てを確認するのは一苦労
① バックアップ
AWS Backup Checker指定した期間内のバックアップが存在するかをAWSのAPIを利用してチェック - EBS snapshot - S3 - AMI
アプリケーションログ、システムログ、アプリケーションデータ
データディスクのスナップショット
Coming Soon.
② AWS障害対策
AWSは障害が少なくて非常に助かってます!
が、
障害を0にはできないのが現実
過去に遭遇した大規模障害
● 2011年4月
us-eastでEBS障害http://interu.hatenablog.com/entry/20110425/1303731515
● 2012年6月
us-eastで電源障害・API障害
障害からの学び
EBS障害が発生すると● EBS bootのAMIは起動不可● EBS上のデータへのアクセス不可
障害からの学び
⇛ DR対策できあがり
● Instance storeタイプのAMIを
別Regionに作成しておく● データも別RegionのS3にバックアップ
で、何を効率化したの?
● 定期EBS snapshot取得スクリプト● EBS boot型AMI作成スクリプト● Instance store型AMIを別Regionに
作成するスクリプト ※要AKIの準備
https://github.com/interu/management_utilities
Fin.