(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
ご清聴ありがとうございました

さくらのクラウド活用事例 - 構成と運用のご紹介(Innovation EGG 第5回 『クラウド運用の本音』)