事業譲渡されたシステムを起動に乗せるまで？

はじめに

この記事はCloud CIRCUS Meetup #1【2022/5/25（水）】 - connpass にて登壇した際のスライドを文字起こししたものになります。

この話は誰向けなのか？ということですが、結論、事業譲渡でサービスの担当者になってしまった方向けです。

まず、IZANAIとはチャットボットのシステムです。2020/12 月に譲渡が発表され、2021/06月にファーストリリースを行いました。Ruby On Rails + Vue.js によって構築されたサービスになります。
実際に事業譲渡するにあたって、どういうものだったのかということについて紹介させていただきます。

構成について

アプリケーション

• 開発環境構築の敷居が高かった
• 仕様書がない
• テストがない
• Ruby on Rails + Vue.js （SPA）の構成であった
• Rails は、APIモードではなく、RESTful ではない

インフラ

• Gitlab CI + Ansible でデプロイしているがメンテナンスがされていない
• Target GroupのヘルスチェックがUnhealthyでAutoScalingの恩恵を得られない
• Production環境、Staging環境、Test環境で利用できる機能に違いがある
• チームメンバーなら誰でも本番デプロイ可能
  • これはまずいですね...
• ログがサーバ内に蓄積されている
  • ログは7日で消える

最初にこのシステムを事業譲渡するというところでチェックしたんですが、まともに動かすのは大変だな....というのが正直な感想でした。

どうしたのか？

では、この状態からどうやって我々のプロダクトとしてリリースしていくのか？開発をしていくのか？軌道に乗せるという点で、下記の4つを挙げました。

• 開発環境を他のプロダクトと同様の構成とする
• 内部仕様を理解し、現在のプロダクトの問題点を明らかにする
• テストする環境を作り、コードの整合性をチェックする環境を作る
• インフラの見直しを行い、デプロイ方法やログの出力方法を合わせる

開発環境を他のプロダクトと同様の構成とする

譲渡された段階では構築できないわけではなかったのですが、ある一定の知識レベルが必要でした。ドキュメントの手順が多く、かつ手動でconfigを編集しなければならなかった。

また、当社の福岡拠点では Dockerによる開発環境の構築が主流という点からANSIBLE, VAGRANTを使ってた開発環境の構築からdockerのへの構築へと切り替えました。

実際の効果

• 他プロダクトからの追加人員に柔軟に対応できるようになりました
• ワンクリックで環境構築できるようになったこと　これが一番大きなことでした
• 追加でパッケージの導入が必要な場合、メンテナンスが容易になる
• 問題が発生した場合に他プロダクトのナレッジを参考にできる

これからの反省点

• コンテナのビルド時間が遅い

内部仕様を理解し、現在のプロダクトの問題点を明らかにする

内部仕様を理解するのに一番いいのは仕様書なんですが、なにせ仕様書がないのでリバースエンジニアリングといい、ソースコードを読んで、内部仕様の理解を深めます。コードリーディング会を社内で実施したり、相手方開発担当者とのリーディング会も開催していただき、とにかく内部仕様の理解を深めて行きます。

実際の効果

• プロフェッショナルの誕生
• アプリケーションの（隠れていた）問題点が見つかる

これからの反省点

• ドキュメントを最新化する

※実際、これでリバースエンジニアリングしたから仕様書できた！と思うと違くて、、、、
仕様書作るのは本当に面倒
（今後の展望）
→ OpenAPI（Swagger）を用いたAPI仕様書の整備
→ 機能仕様は a5doc etc…
→ シーケンス図やクラス図はPlant UML系でコードで管理

テストする環境を作り、コードの整合性をチェックする環境を作る

まず、Docker上でテストを実行できる環境を作成します。この段階では、Seed やDatabase Cleanerが入ってなかったので導入しました。RSpecによるコードテストを作ってみたり、factory や association の定義も不足があったので、定義し直しを行っております。

実際の効果

• 正しい値が本当に正しいのか検証可能に
  • 開発者目線で目に見えて正しいというのはわかると思うんですが、コードレベルで正しいと言われるのを検証可能になり、レビュアーの負担軽減につながってます

これからの反省点

• テスト実行時間が遅くなっている
• 無駄なテストの精査
  • 1ファイルにあたり、100件ぐらいのテストを作ってしまっているので、無駄なテストを精査して、軽くしていくかつ効率的なテストを作るということになります。

インフラの見直しを行い、デプロイ方法やログの出力方法を合わせる

イメージ編

• Ansible + PackerによるAMIの作成に対応
  • 冪等性のあるサーバ構築を可能に

ログ編

• AWS Cloudwatch Agentを導入
• ログをS3に格納することにより、ログの長期保存を可能に

デプロイ編

• Gitlab CI/CD → CodePipeLineでのデプロイへと変更
• Code Commitへとpushできるユーザーの制限
• CodePipeLineでBlue/Greenデプロイへ
• Fukuoka Devが一般的に利用しているデプロイ方法へ

（余談） Unhealthy 問題の解決

Railsの設定で、強制的にSSLにリダイレクトされていたところをリダイレクトしないようにして、通すようにしています。

config/environments/production.rb

  config.force_ssl = true
  config.ssl_options = {
    redirect: {
      exclude: -> request { request.path =~ /health_check/ }
    }
  }

実際の効果

• Unhealthy がHealthyになったため、CodeDeployでのデプロイが可能に
• Cloudwatch でログを蓄積することより、過去のログが参照可能に
• インフラチームに他プロダクト同様、調査依頼をしやすく

これからの反省点

• Rails Gem から Slackへのアラート通知
  • Cloudwatch Alarm → SNS を利用した通知へ

施策によって得られた恩恵

• 開発環境の簡素化によるメンバーの追加に強くなった
• テストの導入による継続的かつ手戻りのない開発
• インフラ構成見直しによる、脆弱性・不安要素の削減

担当することになったらこれだけはやっとくべき

• 郷に入っては郷に従え（開発環境・インフラ）
• 誰も管理できなくなる前に、他のプロダクトがスタンダードになっているなら合わせる
  • ここが一番重いので絶対最初にやる
• リバースエンジニアリング
  • 全部見た、神クラスも見た
• 仕様書があっても大抵は最新化されていない可能性が高い
• 簡単でいいのでテストを実行できる環境を作る
• テストを実行するための環境を作るだけでも大変だったりする

ありがとうございました！