Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
1
Help us understand the problem. What are the problem?

More than 3 years have passed since last update.

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

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

前置き

グラフ:目標レベル

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

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

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

本題

1.あなたのプロジェクト用SREとは?

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

なぜ?

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

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

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

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

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

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

2.SRE==経費節減、ではない

「スタッフが足りないんですけどー」

に対する改善案の筆頭は常に「採用しろ」です。

「CPUやメモリがいっぱいいっぱいなんですけどー」

に対する改善案の筆頭は常に「増強しろ」です。

経費節減は、数ある目的の一つでしかなく、改善には費用の追加を伴うものが数多くあります。

予算の手当のないSREの掛け声だけでは何も変えられませんよー

3.じゃあ何から手をつける?

まずセキュリティです。

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

1 . セキュリティ:基本

セキュリティの基本は「多層防御」「各層で攻撃を緩和(0には出来ない)」です。

パスワード認証してるからOK?

それって1階層しか防御してないですよね。

地道に対策を重ねて多層にしましょう。

2 . セキュリティ:ssh

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

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

    「デザイナーがuploadするからパスワード認証」が残ってませんか?

    鍵認証に変更しちゃいましょう。すぐに。
     

  • 2-2 . 対策2.sshポートを変更する。

    22番ポート → 1022番ポート とかに変更し、22番ポートはクローズしましょう。

    たったこれだけで、攻撃量が 1/100 以下に激減します。

    やらない手はありません。

    ただし、222番ポートとか2222番ポートは既に攻撃対象になってます。

    もっと変な(予測しづらい)番号にしときましょう。
     

  • 2-3 . 対策3.IPアドレス制限する。

    事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。

    IPアドレス制限は「最も硬い防御」の1つです。

    かけられるなら、すかさずかけてしまいましょう。
     

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

webの脆弱性も狙われます。

/phpmyadmin/ とか、/wp-admin/ とかですね。

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

    無差別に狙われるのは、80番ポート、443番ポートの2つだけです。

    開発サーバのポート番号は、80番ポート、443番ポートから変更しましょう。

    これだけで、攻撃量 1/100 になります。
     

  • 3-2 . 対策2.IPアドレス制限する。

    事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。

    IPアドレス制限は「最も硬い防御」の1つです。

    かけられるなら、すかさずかけてしまいましょう。

    /phpmyadmin/ とか、 /wp-admin/ とか。
     

  • 3-3 . 対策3. URLのディレクトリを1階層増やす。

    無差別に攻撃されるのは、/ 直下のURLです。

    /phpmyadmin/ とか、 /wp-admin/ とか。

    なので、

    • / → location /a/
    • /a/ → phpサーバ
    • /,/a/以外 → nginxで拒否

    のように1階層増やすと、phpサーバで受ける攻撃量が激減します。

    多くのPHPフレームワークは、全URLを /index.php に吸い込む形になってるので、

    攻撃発生 → 破られないまでも、多数アクセスによりphpサーバの性能激低下、

    になる事が多いです。

    これ、設計時にディレクトリ1個挟むだけでものすごく緩和できるのですが、

    そうしてるサイトは見たことないです。

    OPEN後に、こんなURL変更はほぼ無理なんで、設計時にここまで考えてURL設計しましょう。
     

4.次に手をつけるのは?

ログ設定です。

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

webサーバのログ、デフォルトのcombinedには、処理時間入っていないですね。

真っ先に入れましょう。

どの画面が重いのか、計測を始めるのが先です。

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

最終的には GCP bigquery にログ投入するのがよいのですが、そんなのは遠い将来の話です。

fluentd で MySQL とかに投入しておきましょう。

3 . 集計ツールを入れる

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

4 . 集計する

あなたのプロジェクトのピーク時は何時から何時までですか?

インターネット全体の傾向としては、21時-23時だそうですね。 https://it.srad.jp/story/17/02/20/0310205/

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

の2つが2大巨頭です。

この2つを集計ツールで見える化しましょう。

結論

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

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
1
Help us understand the problem. What are the problem?