スタートアップ インフラアンチパターン

スタートアップ × インフラ

〜爆速開発を行う4社の開発を支えるインフラ戦略〜

株式会社FABRIC TOKYO

CTO 中筋 丈人

自己紹介

中筋 丈人

株式会社FABRIC TOKYO CTO

略歴:

  • 陸上自衛隊 重迫撃砲副砲手
  • SIer インフラ構築/業務システム開発 など
  • NHN系 サービス企画/インフラエンジニア
  • Amazon 
  • 現職

@takenakasuji

今日の話

時間的制約、スキル的制約、ヘッドカウント的制約など様々な制約をかかえるスタートアップにおいて、

ありがちなインフラのアンチパターンを実例をもとに紹介し、知見を共有します。

今日の話

時間的制約、スキル的制約、ヘッドカウント的制約など様々な制約をかかえるスタートアップにおいて、

ありがちなインフラのアンチパターンを実例をもとに紹介し、知見を共有します。

闇のインフラとの戦いの記録

前提

  • サービスローンチ1年時点でジョイン
  • インフラ専任のエンジニアは当時から不在
  • もともとのインフラはベンダーさんやそれまでにいたエンジニアが構築

インフラ構成

EC2

ECシステム

EC2

ELB

RDS

(Multi-AZ)

RDS

(Read Replica)

EC2

生産管理システム

EC2

ELB

可視化

抽出

アップロード

セグメンテーション

ユーザ属性設定

  • S3
  • SES
  • Lambda
  • Athena
  • CloudFront
  • Mackerel

可視化

セキュリティグループ欠乏症パターン

(; ̄Д ̄)なんじゃと?

セキュリティグループ欠乏症パターン

症例

セキュリティグループが欠乏していることで、どこからでもアクセスが試行できる状態になってしまっていた。また、パブリックアクセスもenableな設定だった。

※ユーザ、パスワードは適切に設定してあります

治療法

RDSにアクセスするSGにInbound ruleを限定。また、SG全体の設定に疑義が生じたので速やかにauditを行った。

Semi-AZパターン

EC2

ECシステム

ELB

RDS

(Multi-AZ)

ap-northeast-1a

工工エエエ(´Д`;)エエエ工工

Semi-AZパターン

症例

冗長構成が中途半端な状態。ELBとRDSはMulti-AZな設定になっているが、EC2は片肺にだけ1台設置されているので可用性が低い。

※High-Trafficなシステムは意図的に片肺にする場合もあり

治療法

  • EC2もMulti-AZな構成にする
  • スケールアップよりもスケールアウト
    • なぜか無駄に大きいインスタンスが立ち上がっていた。。

ステートフルパターン

EC2

ECシステム

EC2

ELB

RDS

(Multi-AZ)

社内ユーザ

記事投稿

画面

ECサイトにお知らせを掲載するためのCMS的な機能が実装されている。

社内ユーザは記事と写真を投稿することができる。

投稿した写真はEC2の/public/images的なディレクトリに保存される。

( ゚д゚) ・・・
 
(つд⊂)ゴシゴシ
 
(;゚д゚) ・・・
 
(つд⊂)ゴシゴシゴシ
_, ._
(;゚ Д゚) …!?

ステートフルパターン

症例

ELBに振り分けられたEC2の/public/imagesに写真が保存されるため、その投稿を閲覧しようとした際、他のEC2に振り分けられると画像がNot Foundになる。サーバを複数台構成(Semi-AZパタターンの解消)にしたら発覚。

治療法

短期的解決

  • lsyncdでアップされた画像をサーバ間で転送

長期的解決

  • S3に画像を保存
  • 画像だけでなくログファイルもEC2には保存しない
  • とにかくEC2にはステート(状態)をもたない

Single-VPCパターン

EC2

Production

EC2

ELB

RDS

EC2

Staging

EC2

ELB

RDS

VPC

工工エエエ(´Д`;)エエエ工工

Single-VPCパターン

症例

本番環境とステージング環境が同じVPC内に存在している。

加えてSGも細分化されていない。VPCの設定やSGの変更を加えたくとも本番環境への副作用が未知数になり、サービス開発の妨げとなる。

治療法

短期的解決

  • SGをSingle-VPCに最適化しセキュリティリスクを最小化
  • 具体的には、細かく分割し本番環境への副作用をなくす

長期的解決

  • VPCを分けましょう
  • システムが多い場合はAWSアカウントからわける方法もあり

Rootアカウント運用パターン

ガクガク((( ;゚Д゚)))ブルブル

Rootアカウント運用パターン

症例

アカウント開設後、IAMを使用せずにRootアカウントでManagement Consoleへのログインや各種設定などを行なっている。

治療法

  • Rootアカウントには強度の強いパスワード、MFAを設定し、基本的に使用せず寝かせる
  • メンバーの役割、システムの観点でIAMでグループやユーザを作成し、運用する

勘所

  • セオリー通りは本当に大事
    • ​公式やコミュニティのドキュメントをちゃんと読む
    • AWSのベストプラクティスやホワイトペーパーなど
  • ​スタートアップ支援プログラムを利用する(AWS Activateなど)
    • ​クラウドインテグレーターもプログラムを提供
  • だれかをDisるのではなくどうすれば解決するかにフォーカスする
  • 少ない人数で開発しているので、問題の本質を見極め短期的な解決と長期的な解決の二軸で修正を続けていく

We're Hiring!!

  • サーバサイドエンジニア
    • カスタムオーダーECサイトの開発
    • 生産管理システムの開発
  • フロントエンドエンジニア
    • カスタムオーダーECサイトの開発
    • React / Vue.js使用
  • UIデザイナー

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

Made with Slides.com