スタートアップしてからの失敗の数々

Transcript

1. スタートアップしてからの失敗の数々
   2018.3.10 @phperkaigi2018
   

   View Slide

2. - Software Engineer (CyberAgent group)
   - @nakamura_tsuyo4
   - Makuake
   - 創業エンジニア (from 2013)
   About me
   

   View Slide

3. Makuakeはスタートアップ時のメイン言語として
   PHPを採用しています。
   無い無いづくしのスタートアップですが、過去を振り返りここは妥協
   せずにやっておけば良かったなどを紹介します
   前段
   

   View Slide

4. たくさんあるので早速いきます
   

   View Slide

5. 1
   ---
   過度なファイルの存在確認処理
   s3に保存している画像のfile_exists(AWS
   SDK)処理が至る所に存在。
   = インターネット経由でAPIをコールしまくってい
   る。performanceは引きづられる
   > そもそもファイルの存在確認が必要な場面を
   見極める。必要な場合であっても1度file_exits
   した結果をストレージに置いておくべきだった
   

   View Slide

6. 2
   ---
   preg_matchの多用
   preg_matchじゃなくても良い場面でも
   preg_matchを使ってた。
   > そもそもpreg_matchしなくても良い設計はな
   いか、多くの場合はstrposで代用できて、とても
   高速
   

   View Slide

7. 3
   ---
   ImageMagic運用
   元画像から綺麗にサムネイルを作る要件に対
   して自前でImageMagicをインストールしてオン
   デマンドに活用してた。
   > Lambdaで非同期的にサムネイルを作る方法
   もあるけど、そもそもサムネイル+CDN配信して
   くれるsaasを活用した
   

   View Slide

8. 4
   ---
   AWS SESの上限を使い切ってしまった
   メールを送信できる上限が決まってます。がそ
   の閾値を見逃して上限に達してしまい、メール
   が送れない問題
   > すぐに上限緩和依頼。監視の追加
   

   View Slide

9. 5
   ---
   不要になったtableがたくさん
   過去使ってたけど今は使ってないテーブルが多
   数。しかもめっちゃレコード持ってるDBの
   Aurora移行の時に見積りに影響。
   > 不要になれば期限を決めてdrop tableしま
   しょう。とりあえずとっておくではなくて、N日まで
   に使わなかったら消すとかbackupして消すが
   必要
   

   View Slide

10. 6
    ---
    Unuse method classたくさん問題
    利用されていないコードが沢山散らばっていて
    可読性が悪く開発効率がみるみる落ちる
    > IDEなどから不要なものは念のためgrepして
    消すリリースを繰り返した。total:300PR’s。
    Phanも活用
    

    View Slide

11. 7
    ---
    Blogシステムを自前で運用
    SEOに効果あるっぽいから同じサービスの
    domain内でblog記事を運用したい...が、効果
    が未知数なものを運用していくツラさ
    > SEOは無視できないけど自分たちの本業の
    サービス開発に集中すべし。クオリティーの高
    いサービスを提供することが一番のSEO対策!!
    結局外部blogサービスへ引越した
    

    View Slide

12. 8
    ---
    ハウスキーピング意識の欠如
    とりあえずログを取っておくで放置されるパター
    ンが後々、ログが肥大化してdiskを食いつぶし
    たり問題が表面化
    > 無駄にログを溜め込まない。N日経って不要
    となるものは積極的にpurge処理を追加
    

    View Slide

13. 9
    ---
    外部API 変更を見逃しての障害
    通知はだいたいメールのみ。それを忘れさら
    れ、或る日突然エラー
    > メールだけでは気づかないのでslackへの通
    知や通知をメールをメーリス化で
    

    View Slide

14. 10
    ---
    mysqlのレコードに0とnullが同居問題
    プログラムの作り上、ケアすべきことが増え、冗
    長になっている
    > プログラムを修正して蓋をする
    過去のデータを洗い替えするバッチで一気に修
    正
    今後はdev環境にSQLモード設定を検討
    

    View Slide

15. ここまでは技術的な話
    

    View Slide

16. 組織的な話を少々
    

    View Slide

17. 11
    ---
    コードを書く以外の役割
    少しTeamが大きくなると必然と古株にマネージ
    メント的要件や社内情シスのような役割を求め
    られるようになる。
    思考と合えば良いが、今後もバリバリコードを
    書いてプロダクト開発したいと思考しているとツ
    ライ
    > PM的な役割の人を早めに採用すべし
    

    View Slide

18. 色々と話してきましたが、何は妥協すべき
    でなかったのか？
    

    View Slide

19. ❏ もっと必要最低限の機能に絞れば... (MVP)
    ❏ 後発サービスとしては難しい面もあるけど...
    ❏ 本来集中すべきコア機能などに集中
    ❏ 提供するものを小さくすることで運用コストを下げる
    ❏ 役割が変わったなと感じ、不満に思えば早めに 1
    on 1
    ❏ 流れに任せてなんとなくその役割を担うのはリスク
    

    View Slide

20. おまけ（実は）
    

    View Slide

21. スタートアップのエンジニアになることはそれなりの苦
    労があります
    遊んでいる暇などなく、ひたすら仕事します。
    システム・組織のトラブルなど日常になります。
    この状況を下支えするモチベーションが必要
    

    View Slide

22. ▸ ゼロから事業を立ち上げをし
    たいと強く思っていた
    In My Case
    人によるけど
    - CEOの思いに強く共感したとか
    - Stock Optionをもらったとか
    多くの困難に立ち向かう為の信念が大事!
    

    View Slide

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

    View Slide