さくらのクラウド活用事例 - 構成と運用のご紹介(innovation egg 第5回...
Post on 08-Jan-2017
422 views
TRANSCRIPT
(C)Copyright 1996-2015 SAKURA Internet Inc.
さくらのクラウド活用事例 構成と運用のご紹介
2015年10月31日
さくらインターネット研究所 所長 鷲北 賢
2
自己紹介
• 鷲北 賢(わしきた けん) – 1998年4月入社(さくらインターネットの前身会社)
– バックボーンのお守りからサービス開発まで • 初期の専用サーバ、データセンター構築
• オンラインゲームプロジェクト
• CTO兼取締役、などなど
– 2009年より、さくらインターネット研究所 所長 • 仮想化技術の研究(Linux KVM)
• さくらのVPS開発ヘルプ
– 2011年さくらのクラウド 開発チームリーダー兼務
– @ken_washikita
– http://facebook.com/ken_washikita
3
アジェンダ
1. 小さく始めて、大きく育てたい
2. アクセス数に合わせて増やしたい
3. セキュリティに気を配る
4. サービス監視をしっかりと
5. その他のトピック
4
サービスサイト、どう作る?
• 小さく始めて、大きく育てたい – 開始当初は最小構成で
• アクセス数に合わせて増やしたい
– いざというときに大きくできるようにしたい – 不要になれば減らしたい
• セキュリティに気を配る
– 不要なものは見せないように – メンテナンスは専用経路で
• サービス監視をしっかりと
– ログやグラフをきちんと管理したい
5
典型的なサーバ構成
App1 App2
DB master
ルータ VPC ルータ
メンテナンス用
DB repl
Internet
ロード バランサー
ロード バランサー
Zabbix
6
小さく始める
• 最小構成・一台のサーバから
• 開発・テスト環境は1台で充分
• ルータもオプションで –後のことを考え、余裕があれば置く
– LBを置くときに必要になる
– IPを節約する場合も必要
• 性能が足りるのならこれでも十分
App/DB
ルータ
Internet
7
DBを分離する
• データベースは分けておきたい
• セキュリティ
– DBサーバはグローバル・不特定多数に晒したくない
• 性能確保
– Appへの負荷に影響されたくない
– DBならではのチューニングが施せる
App
DB
ルータ
Internet
8
TIPS (1)
• App/DBサーバの分離 – 元のApp/DBサーバのクローンを作る
– AppサーバではMySQLを落とし、DBサーバではApacheを落とす
– AppからDBへリモートアクセスするよう設定変更
– 慣れれば30分程度の作業で完了できる
• DBへのアクセス – メンテナンス経路がないとアクセスが不便
– Appサーバを踏み台に
– 先にメンテナンス経路を用意するのもよい
9
アクセスが増えると何が起こるか(1)
処理能力
時間
一人一人のアクセスは小さく、処理能力には余裕がある
アクセスが短時間に集まると多くの処理能力を使うようになる
10
アクセスが増えると何が起こるか(2)
処理能力
時間
限界
能力の限界を超えると 処理が待たされる 一人一人のアクセス時間が延び
処理が終わる時間が遅くなる
11
スケールアップ
処理能力
時間
限界
限界
サーバの処理能力を高め限界を上げてアクセスに対処する
12
スケールアウト
処理能力
限界
13
アクセス数に合わせて増やしたい
• スケールアップ
–サーバスペックを向上させる
• スケールアウト
– LBを導入し、分散する
• 冗長(可用性向上)のためにLB導入がオススメ
App1 App2
ルータ
Internet
ロード バランサー
ロード バランサー
14
TIPS (2)
• LBアプライアンス機能
– DSR(Direct Server Return)
–設定はコンパネから
–サーバ設定も若干いじる必要がある
– /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.al.arp_announce = 2
– /etc/sysconfig/network-scripts/ifcfg-lo:0
net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.al.arp_announce = 2
DEVICE=lo:0
IPADDR=xx.xxx.xxx.xxx
15
TIPS (3)
• Appサーバを増やすときはクローンで簡単
–コンパネ操作でも、APIで自動化も可能
–性能監視と組み合わせればオートスケールも可能
• Appは最初から冗長構成できるように作る
–冗長できないシステムは色々ツラい
16
セキュリティに気を配る
• インフラでのセキュリティ設定
– 不要なアクセスはシャットアウト
– 特定ポートのみ開き、他は閉じる
• メンテナンス経路を用意する
– 必要なアクセスは専用に用意
– 認証、暗号化で保護する
App
DB
ルータ
Internet
VPC ルータ
メンテナンス用
17
TIPS (4)
• フィルタ機能 –スイッチでポートフィルタを設定可能
–サーバでiptablesを使うのもアリ
–特定ポート以外をふさぐ設定を入れて保護
• VPCルータ – NAT、VPN、PPTP/L2TP/IPsec、アカウント管理
–ファイアウォール機能
–プライベート側に7つのポートを持つ
–多数のセグメントを持つサイトにも対応
18
サービス監視をしっかりと
• Zabbix – あるいはお好みの監視ツールで
• 情報取得、確認はメンテナンス経路で – Zabbixコンパネのアクセスもセキュリティが必要
– 監視メールの出口もこちらへ
• 監視は重要
– 障害検知時の対処を早くできる – 性能評価のためのデータ収集
App
DB
ルータ
Internet
VPC ルータ
メンテナンス用
Zabbix
19
TIPS (5)
• Zabbix
……の具体的な設定は書籍がたくさんあるのでそちらをご覧ください
• 監視は運用の要(かなめ)
–日ごろからデータを収集しておく
–「異常」を検知するために「正常」を定義する
–「正常」との比較で、異常を検知し原因を絞り込む
–異常検知だけでなく、平時の性能評価に役立つ
20
ところで
21
こんな事例も
LB LB
ルータ
Web1 Web2 Web100 DB1 DB2 …
スイッチ管理が面倒なのでフラットに構成
22
AWS
さくらのクラウド
クラウド・ハイブリッド
RDS
LB LB
ルータ
Web1 Web2 Webn …
VPC
Internet
VPC
Engine
23
クラウド・インスタンスでは性能が不足というケース
• IaaS型クラウドではディスクI/Oがネック – DB専用サービスには叶わない
– ioDriveのような高I/O装置がどうしても使いたい
• GPGPUやその他の特殊なHWが必要なケース
• 部分的にもリソースを占有しておきたいケース
ハイブリッド接続により 物理サーバも使って美味しい所取り
24 専用サーバ
さくらのクラウド
仮想・物理サーバのハイブリッド
DB1 DB2
LB LB
ルータ
Web1 Web2 Webn …
ハイブリッド接続に よりL2接続・通信可能
25
ガイドブック出ています
• ローンチのモデルケースをステップごとにご紹介
• WordPressを例に分かりやすく
• 多くのLAMP環境に応用していただけます
26
ご清聴ありがとうございました