(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

アクセスが増えると何が起こるか（１）

処理能力

時間

一人一人のアクセスは小さく、処理能力には余裕がある

アクセスが短時間に集まると多くの処理能力を使うようになる

10

アクセスが増えると何が起こるか（２）

処理能力

時間

限界

能力の限界を超えると 処理が待たされる 一人一人のアクセス時間が延び

処理が終わる時間が遅くなる

11

スケールアップ

処理能力

時間

限界

限界

サーバの処理能力を高め限界を上げてアクセスに対処する

12

スケールアウト

処理能力

限界

13

アクセス数に合わせて増やしたい

• スケールアップ

–サーバスペックを向上させる

• スケールアウト

– LBを導入し、分散する

• 冗長（可用性向上）のためにLB導入がオススメ

App1 App2

ルータ

Internet

ロード バランサー

ロード バランサー

14

TIPS （２）

• 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 （３）

• Appサーバを増やすときはクローンで簡単

–コンパネ操作でも、APIで自動化も可能

–性能監視と組み合わせればオートスケールも可能

• Appは最初から冗長構成できるように作る

–冗長できないシステムは色々ツラい

16

セキュリティに気を配る

• インフラでのセキュリティ設定

– 不要なアクセスはシャットアウト

– 特定ポートのみ開き、他は閉じる

• メンテナンス経路を用意する

– 必要なアクセスは専用に用意

– 認証、暗号化で保護する

App

DB

ルータ

Internet

VPC ルータ

メンテナンス用

17

TIPS （４）

• フィルタ機能 –スイッチでポートフィルタを設定可能

–サーバでiptablesを使うのもアリ

–特定ポート以外をふさぐ設定を入れて保護

• VPCルータ – NAT、VPN、PPTP/L2TP/IPsec、アカウント管理

–ファイアウォール機能

–プライベート側に7つのポートを持つ

–多数のセグメントを持つサイトにも対応

18

サービス監視をしっかりと

• Zabbix – あるいはお好みの監視ツールで

• 情報取得、確認はメンテナンス経路で – Zabbixコンパネのアクセスもセキュリティが必要

– 監視メールの出口もこちらへ

• 監視は重要

– 障害検知時の対処を早くできる – 性能評価のためのデータ収集

App

DB

ルータ

Internet

VPC ルータ

メンテナンス用

Zabbix

19

TIPS （５）

• 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

ご清聴ありがとうございました