意識の低い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に取り組む時、１にセキュリティ、２に監視(集計)基盤整備してくださいねー