システム現状分析と再構築プラン

現状分析

• 古いシステムがありそちらはクローズをしたい
• 何かしらの追加をしたい時に時間がかかりすぎる
• サーバーダウンする

組織的な問題

• 経営者が開発に関与しすぎ
• システムの裏側の負債の問題について無視しすぎ
• 社員の業務生産性について目を背けすぎ

システム上の設計問題

• 運用効率の悪さ
• 自動化の未完成
• データモデリング
• Rubyパフォーマンスの悪さ
• AWSの設計の可用性の低さ
• コストの悪さ

SIerの方法だと

• ビッグバンリプレイス
  • Rails→他言語へのリプレイスして全部置き換え
• 言語の総置き換え

捨てた選択肢

• 細かい要望を止める
  • 窓口を減らし
  • 開発者の窓口をPMにしてもらう
    • PMから開発者へ相談をしてもらう
    • 営業やサポートはPMに介して開発者への要望をしてもらう
      • その間開発者は業務を効率化させる
      • システムの直し

実践するべきと判断したこと

• システム開発の主導
• 負債の返済
• 業務生産性を上げるための業務自動化

やること

• AWSサーバーを冗長化して可用性を上げる
  • EC2インスタンスを冗長化
    • オートスケーリンググループを作成してオートスケールする
    • 障害に備えてDR対策
      • フェイルオーバーの仕組み
        • アクティブ-パッシブの構成
        • 最小構成で置いておく
          • 稼働したら自動スケール
  • DBをレプリケーション
    • 読み取り専用と書き込み専用で分ける
    • マルチAZにする
  • サーバーをコンテナ化
    • EC2インスタンスからECSへの移行
    • デプロイはECRへDockerイメージを置く
  • コスト最適化のためのサーバーレス化
    • 管理者操作のDBはAuroraServerlessで局所的な使用方法にする
    • リザーブドインスタンスで1〜3年のEC2インスタンスの契約をする
      • コアドメインはEC2インスタンス
    • 送客ロジックをコンテナ化
      • Lambdaで運用15分稼働とコールドスタート
      • 分離したロジックの言語は自由にしてよい
      • Python ? Go ?
      • API化してAPI通信＋メッセージキュー
      • SQS,  RabbitMQ
    • キューイングシステムを再構築
    • 冪等性を確保
    • 状態管理テーブル
    • Gemでsidekiq-unique-jobs
  • 運用を効率化
    • サーバーのフルマネージド化
    • Aurora、ECS/Fargate、Lambda、DynamoDB
    • 可観測性
    • フルマネージドにするためEC2ストレージに直接吐いていたログを集約
    • Fluentd、CloudWatch
    • デプロイの自動化
    • CodePipeline？
    • Github Actions?
    • 日々の作業で非効率的な手動の作業を減らす
      • トイルの削減
      • バッチ化
      • スケジュールではなく分離していく
• パフォーマンスを測定してボトルネックを解消する
  • DataDogを使用して、クエリを特定
    • Explainなどでスロークエリを分析
  • gem BulletでN+1の発生しているActiveRecordを抽出
    • ActiveRecordが作るクエリを分析し、ボトルネックを探す
      • N+1修正をしてボトルネックを解消
• DB設計をしてデータモデルを再構築する
  • 負債によって一番開発効率が下がっている部分を特定
    • コアドメインのデータモデルを再構築する時間を取る