運用・保守性を高めるためにやった事

運用・保守性を高めるためにやった事
スタートアップで開発している（したい）エンジニア交流会 LT
2020-03-25

自己紹介
Takuya Narita (25) / Engineer
2017-04 ~ 2018-09 株式会社アドウェイズ (新卒入社)
2018-10 ~ 2019-12 スタートアップ2社経験
2020-01 ~ 現在株式会社テックピット
経歴

そもそもスタートアップとは？

Brandon K. Hill.
btrax, Inc.
スタートアップとは
新しいビジネスモデルを開発し、ごく短時間のうちに急激な成長と
エクジットを狙う事で一獲千金を狙う人々の一時的な集合体

特にシード期のスタートアップ
● 事業アイディアを立案して間もないフェーズ
● そのアイディアの事業モデルの価値仮説や成長仮
説などを高速に検証していくフェーズ
● 高速な検証サイクルによりPMFを目指す
● 少ないシード資金でこれらを達成していく
● ...

● ...
特にシード期のスタートアップ
Techpitは現在このフェーズ
👈

● ...
特にシード期のスタートアップ 👈
🏃
♂️
なので開発速度をかなり要求される

プログラミング学習教材のマーケットプレイスとして
教材作成者と購入者をマッチング
👨
💻
👨
💻現役
エンジニア
プログラミング
学習者
教材を販売教材を購入
料金料金

Techpitの開発背景
● 事業モデルを最速で検証
するために開発を行わず
にTeachableというPaaS
を利用してプロトタイプ
をリリース
● ツイートの反響後, 約1週
間でプロトタイプ公開
● Techpitのコンセプト
についてのツイート
で大きな反響を獲得
SNSによる
ニーズ検証
PaaSを利用した
プロトタイプ
構築
業務委託主導で
MVP開発開始
● プロトタイプ公開後は様々な検証
と並行してMVPの内製開発
● PaaSに乗っかると改善施策が打
ちづらい & 制限などにより新機能
などは作り込めないので当然プロ
ダクトは内製化したい

● 業務委託の方から引継ぎ中
● 追加機能などは自分が着手
現在
自分と業務委託
で
MVP開発中

● 業務委託の方から引継ぎ中
● 追加機能などは自分が着手
現在
自分と業務委託
で
MVP開発中
インフラの設計・構築
フロントエンドの設計・開発
バックエンドの設計・開発

私がジョインした時には実装計画の
8割程度は完成していた ⚒

が、、、
引継ぎ＆機能改修などがなかなか進まない、、、 😇

どんな問題があったのか？

フロントエンド
● 色んなページで同じようなマークアップが散在している
⇒ UI改修する時にgrepしてひとつずつ改修しなきゃいけない
● Viewに大量のロジックが含まれている
⇒ 可読性悪い & 保守性低い
● 文字列をマークアップに直接書いている
⇒ 短期中期的には多言語化対応しなくてもいいからまぁ後から
でもいいか...
😇
😇
😇

バックエンド
● 大量のN+1
⇒ 多い箇所だと1リクエストあたり30クエリほど...
● エラーレスポンス設計がちょっと雑
⇒ 例外時はとりあえずHTTP Status 400 Bad Request返してるだけ
😇
😇

インフラ
● ドキュメントがあまり無い & 整備されてないので引継ぎが困難
⇒ 結論言うと引き継げなかったので自分で再構築することに...
😇

1. フロントエンド
2. バックエンド
3. インフラ
アジェンダ
Techpitで運用・保守性を高めるためにやったこと

● nuxt v2.2.0
⇒ Vue.jsのプログレッシブフレームワーク
● typescript v3.1.3
⇒ 静的型付け
● eslint v5.7.0
⇒ 静的コードアナライザー
● prettier v1.14.3
⇒ コードフォーマッター
Techpitのフロントエンド
※ 主要なライブラリのみ記載

フロントエンド
● 色んなページで同じようなマークアップが散在している
⇒ UI改修する時にgrepしてひとつずつ改修しなきゃいけない
● Viewに大量のロジックが含まれている
⇒ 可読性悪い & 保守性低い
先ほど列挙した問題点

Atomic Design & Storybookの導入により
コンポーネント設計の見直し 💡

components/
├── atoms/
├── molecules/
├── organisms/
├── templates/
└── sp/
├── atoms/
├── molecules/
├── organisms/
└── templates/
● 開発速度優先のため機能改修しながら都度Atomic
Designに寄せていった
● レスポンシブ対応によりデバイスによって, そもそも要
素の構造が変わるものは別のComponentとして扱う
画面サイズ(デバイス)によってコンポーネントを出し分
けする処理はJSでハンドリング
● Storybookは現在導入中...

Container ComponentとPresentational Componentは
別に実装する 💡

参考
@HayatoKamono, Vueを用いた開発プロジェクト用に「コンポーネント設計・実装ガイドライン」を作った話
https://qiita.com/HayatoKamono/items/72b02d439a83d68fc15a#container-component%E3%81%A8presentational-component
可読性・保守性の向上
● データや振る舞いに関心を持つContainer Componentと、見た目に関心を持
つPresentational Componentに分離することで、どこに何が書かれているか
が分かりやすくなる
再利用性の向上
● Container ComponentとPresentational Componentに分けることで、
Presentional Componentが特定のVuex側で持っている状態に依存しなくなり、
他の異なるデータソースに差し替えても使い回しが出来るようになる
その他様々な利便性が向上
● ...

Techpitのバックエンド
● rails v5.2.3
⇒ サーバサイドフレームワーク
● rollbar v2.19.3
⇒ エラートラッキング
● brakeman v4.5.1
⇒ N+1を検知するためのライブラリ
● rspec-rails v3.8.0
⇒ テストフレームワーク
※ 主要なライブラリのみ記載

バックエンド
● 大量のN+1
⇒ 多い箇所だと1リクエストあたり30クエリほど...
● エラーレスポンス設計がちょっと雑
⇒ 例外時はとりあえずHTTP Status 400 Bad Request返してるだけ

N+1が含まれていたらマージしない
(運用でカバー) 💡

N+1が含まれていたらマージしない
(運用でカバー)
一応N+1を検知するライブラリが導入されていが,
何故かちゃんと運用されてなかったので運用体制を厳しくすることに

まだ何も対応策を打てない... 😅

インフラ
● ドキュメントがあまり無い & 整備されてないので引継ぎが困難
⇒ 結論言うと引き継げなかったので自分で再構築することに...

Techpitのインフラアーキテクチャ

● ECSによるコンテナオーケストレーション
⇒ 高可用性、拡張性は担保されている
⇒ デプロイ時はECSサービスをRolling Updateしているのでダウンタイムも無さそ
う (Zero-downtime)
● 単一障害点は無さそう
⇒ 一見Route53は単一障害点に見えるがAWS側で冗長構成を取っているので問題
無い
● セキュリティグループも必要最小限のインバウンドしか許可していない
⇒ 割とセキュアっぽい
● その他非機能要件項目も一見良さそう
Techpitのインフラアーキテクチャ

インフラリソースをAWS CDKでIaC管理 💡

もちろんドキュメントに残しながら & 構築時の作業ログも残しつつ
インフラリソースをAWS CDKでIaC管理

保守性の向上
● プログラミング言語でオブジェクティブに記述できるので複数スタック間の
依存関係が明確になる
● 引継ぎなども楽になる
⇒ コードを見たらだいたいわかる状態
運用体制の強化
● インフラリソースの設定変更や構成変更はCDKで行う
● マネジメントコンソール(手動操作)は原則禁止
⇒ インフラが起点となってインシデントが発生した時などのみ許可

● 最初からより良い設計を目指す
⇒ とはいえ速度も優先しないといけないのでリスクを把握した上で妥協する
● インフラやアプリケーションのアーキテクチャはドキュメントにちゃ
んと残す
⇒ 何が起きるかわからないのでちゃんと残すべき
まとめ

Techpitで執筆していただける方を募集してます
&&
エンジニアも採用中です
さいごに

ご静聴ありがとうございました
🙇
🏼♂️

運用・保守性を高めるためにやった事

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 運用・保守性を高めるためにやった事

Semelhante a 運用・保守性を高めるためにやった事 (20)

運用・保守性を高めるためにやった事

Notas do Editor