意識の低いSRE SREに取り組む時の話

前置き

目標レベル	レベル0 技術負債山 (地盤沈下中)	レベル1 高尾山	レベル2　　　富士山	レベル3　　　エベレスト山	レベル4　　　オリンポス山 (火星)
段階	オンプレで LAMP構成	クラウド化	マイクロサービス化	パブリッククラウドフル活用	世界中に自社データセンターや海底ケーブル
例	10年前に作ったシステムのまま	ここ数年で作ったシステム	2014年のクックパッドの報告が有名	Netflix, Pokemon GO, ...	Amazon, Microsoft, Google, facebook, ...

レベル１のプロジェクトは、レベル４のプロジェクトとは違った物事の進め方になる、の話です。

オンプレでLAMP構成な人向けです。

本題

１．あなたのプロジェクト用SREとは？

google社のSREそのまんまは、あなたのプロジェクトには向きません。

なぜ？

google社の特長はこんな感じです。

予算超潤沢。
スタッフ超優秀。
監視(集計)基盤整備済み。分析からスタート。

どうですか。この夢のような環境は。

あなたのプロジェクトはきっとこんな感じです。

予算無い。
スタッフ募集しても採用に至らない。
監視(集計)基盤整備からスタート。

google社のような規模感はあきらめて、もっと地に足のついた取り組みから始めましょう。

２．SRE==経費節減、ではない

「スタッフが足りないんですけどー」
に対する改善案の筆頭は常に「採用しろ」です。

「CPUやメモリがいっぱいいっぱいなんですけどー」
に対する改善案の筆頭は常に「増強しろ」です。

経費節減は、数ある目的の一つでしかなく、改善には費用の追加を伴うものが数多くあります。
予算の手当のないSREの掛け声だけでは何も変えられませんよー

３．じゃあ何から手をつける？

まずセキュリティです。
SRE以前の話として、セキュリティ不備はNGですよね。

1 . セキュリティ：基本

セキュリティの基本は「多層防御」「各層で攻撃を緩和(0には出来ない)」です。
パスワード認証してるからOK？
それって１階層しか防御してないですよね。
地道に対策を重ねて多層にしましょう。

2 . セキュリティ：ssh

sshは、「何でも出来る」強すぎる権限を持つことから、真っ先に攻撃されます。

2-1 . 対策１．ssh鍵認証にする。

「デザイナーがuploadするからパスワード認証」が残ってませんか？
鍵認証に変更しちゃいましょう。すぐに。
　
2-2 . 対策２．sshポートを変更する。

22番ポート → 1022番ポートとかに変更し、22番ポートはクローズしましょう。
たったこれだけで、攻撃量が 1/100 以下に激減します。
やらない手はありません。
ただし、222番ポートとか2222番ポートは既に攻撃対象になってます。
もっと変な(予測しづらい)番号にしときましょう。
　
2-3 . 対策３．IPアドレス制限する。

事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。
IPアドレス制限は「最も硬い防御」の１つです。
かけられるなら、すかさずかけてしまいましょう。

3 . セキュリティ：http,https

webの脆弱性も狙われます。
/phpmyadmin/ とか、/wp-admin/ とかですね。

3-1 . 対策１．開発環境はhttpポート、httpsポートを変更する。

無差別に狙われるのは、80番ポート、443番ポートの２つだけです。
開発サーバのポート番号は、80番ポート、443番ポートから変更しましょう。
これだけで、攻撃量 1/100 になります。
　
3-2 . 対策２．IPアドレス制限する。

事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。
IPアドレス制限は「最も硬い防御」の１つです。
かけられるなら、すかさずかけてしまいましょう。
/phpmyadmin/ とか、 /wp-admin/ とか。
　
3-3 . 対策３． URLのディレクトリを１階層増やす。

無差別に攻撃されるのは、/ 直下のURLです。
/phpmyadmin/ とか、 /wp-admin/ とか。
なので、
- / → location /a/
- /a/ → phpサーバ
- /,/a/以外 → nginxで拒否
のように１階層増やすと、phpサーバで受ける攻撃量が激減します。
多くのPHPフレームワークは、全URLを /index.php に吸い込む形になってるので、
攻撃発生 → 破られないまでも、多数アクセスによりphpサーバの性能激低下、
になる事が多いです。
これ、設計時にディレクトリ１個挟むだけでものすごく緩和できるのですが、
そうしてるサイトは見たことないです。
OPEN後に、こんなURL変更はほぼ無理なんで、設計時にここまで考えてURL設計しましょう。

４．次に手をつけるのは？

ログ設定です。

1 . webサーバのログに、処理時間を追加する

webサーバのログ、デフォルトのcombinedには、処理時間入っていないですね。
真っ先に入れましょう。
どの画面が重いのか、計測を始めるのが先です。

2 . webサーバのログを、MySQLとかに投入する

最終的には GCP bigquery にログ投入するのがよいのですが、そんなのは遠い将来の話です。
fluentd で MySQL とかに投入しておきましょう。

3 . 集計ツールを入れる

RedashかMetabase入れて、集計できるようにしましょう。

４ . 集計する

あなたのプロジェクトのピーク時は何時から何時までですか？
インターネット全体の傾向としては、21時-23時だそうですね。 https://it.srad.jp/story/17/02/20/0310205/

ピーク時内の画面別処理時間合計が最大の画面
ピーク時内の画面別アクセス数が最大の画面

の２つが２大巨頭です。
この２つを集計ツールで見える化しましょう。

結論

SREに取り組む時、１にセキュリティ、２に監視(集計)基盤整備してくださいねー