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