レガシーシステムをリプレイスして古の遺産を浄化した話
まえがき
タイトルの通り、少し前に 8 年近く（正確な歴史は不明）動いていたシステムをリプレイスしました。
かかった期間は約 2 年、発行した課題チケット数は 6000 超え、リリース直前に直属上司が退職など紆余曲折ありました。
良かった点や反省点が多くあったので、記憶が新しいうちにアウトプットしようと思います。
なぜリプレイスするのか
単純にエンジニアが「レガシーだからモダンな環境にリプレイスしたい」と言っても、事業責任者や経営層にメリットを理解してもらえないと実施できません。
今回は後述する問題によって、事業の足を引っ張っているという結論が出たためリプレイスに至ったと認識しています。
セキュリティの問題
システムの問題
- フレームワークのコア部分を魔改造
- 一度リプレイスしようとして失敗した昔の残骸(Python のコード)が残っている
- テストコードがない
- バージョン管理が Subversion
- 密結合
- 1 つのリポジトリを別部署の別サービスと共有している
- サービスA のバリデーション定義を変更したら、サービスB のバリデーション定義も変更されてしまう
- エラーに気づけない（ユーザーからの問い合わせで初めて気づくなど）
- サイトが http
DBの問題
- 1 テーブルのカラムが大量に存在する
- 使用していないテーブルが混ざっている
- 何でも DB で管理しようとしているためデータが複雑化している（〇〇カテゴリーのネスト構造をマスターとして管理など）
- スロークエリ多数
- 命名に一貫性がない
***_table2が存在するm_***_tableのようにマスターテーブルを想起させるプレフィックスが付いていたりするが、実際はマスターではなく頻繁に更新される普通のテーブルだったりする
事業的な問題
- 上述の理由によりデリバリーのスピードが出せず、施策が実行できない（時代の変化についていけない）
- テストが人力のみなのでシステムのクオリティが担保できない
- 枯れた技術を使用しているため、エンジニア採用時の足かせになる（または退職される）
どうリプレイスしたか
ここは書こうと思えばいくらでも具体的にかけますが、キリがないのでざっくりポイントだけ書きます。
システム構成
- オンプレからクラウド（AWS）に移行
- マイクロサービスアーキテクチャ導入
- Frontend ⇔ API Gateway ⇔ API
- API 実装時はテストコード必須に
- PHP は 7 系にアップデートし、フレームワークは Laravel に変更
- MySQL は 5.7 互換の Aurora に変更
- DB は全て再設計し、新テーブル用にデータをコンバート
- 画像系と静的コンテンツは S3 で管理
- インフラ周りは Terraform と Ansible で管理
- フロントエンドは Vue や React で作成
開発方法
- 2 週間ごとにスプリントを切って回していくスクラムを導入
- 課題の管理や進捗の把握は JIRA で統一
- 1 人でフロントエンドからバックエンドまでを担当
- システムとしてどうあるべきかということを先に提案し、なるべく既存システムに近づけてひたすら機能を開発していく
体制
開始時
- エンジニア： 2 名
- プロダクトオーナー（直属上司） 1 名
- 部長： 1 名
終了時
- エンジニア： 5 名
- 部長： 1 名
やらなかったこと
- デザインのリプレイス（リニューアル）
- 単純にデザイナーがいなかったというのと、システムに比べてスタイルガイドなどはかなり丁寧に作られていたのでデザインは踏襲することにしました
- ただ、純粋なコーディング部分は Webpack で管理できるように書き換えました
リプレイスするにあたり追い風だったこと
- リリース当日はサイト停止 OK
- 廃止できる機能が多かった
大変だったこと
旧システムの有識者が 0 の状態からのリプレイス
プロジェクトにアサイン後、唯一の有識者だった派遣社員エンジニアが退職してしまい、手を動かすエンジニアがアサインされたばかりの自分と、入社したばかりの業務委託の方のみになってしまいました。
そのため、かなり手探りの状態からリプレイスプロジェクトが始まり、スタートダッシュができませんでした。
データの移行
データを移行するためにデータコンバーターを作成しました。
「旧DBからデータ取得→バリデーション→新DB用にデータを加工→新DBにインサート」という流れです。
移行するテーブル 1 つひとつに、このロジックとテストコードを作成しなくてはいけないため、かなり時間を費やしました。
また、データの移行を失敗すると取り返しがつかないことが多いので、かなり慎重に行う必要がありました。
パスワードの移行
可逆だったパスワードを不可逆の値にするために一旦復号化する必要がありました。
旧パスワードが pear の Crypt_Blowfish を使用していたため、composer に pear のライブラリを追加しました。。
そして、そのままでは PHP 7 系では動かないので、/pear-pear.php.net/Crypt_Blowfish/Crypt/Blowfish.php を改修することに。。
※ そのときの調査ログ。
工夫したこと
フロントエンドはなるべくサーバーレスに
EC2 インスタンスは結構料金がかかるので、可能な限り SPA で構築することにしました。
SEO 対策が必要なサービスは SSR できる Next と Nuxt を導入して対応しました。
反省点
SEO の影響をなめていた
そこまで SEO に依存していないコンテンツでしたが、それでも目に見えて集客力が下がったため、もう少し真剣に考慮するべきだったと思います。
ちなみに SPA にした影響というよりは、旧 URL からのリダイレクトやエラーページのステータスコード、ページ構成などが主な理由です。
サービス間の連携テストの実施が遅かった
これはマイクロサービスならではですが、各サービス間をまたいだテストをするのが少し遅かったです。
連携テストをして初めてログイン周りの不具合などが見つかりました。
そして、結果的にリリース日を 2 週間ずらすことになってしまいました。。
サービスが属人化してしまった
スピードを重視していたため、1 人 1 サービス（場合によっては複数）を実装してもらうことにしたのですが、そのサービスについて詳しい人物が限定されてしまいリスクを生んでしまいました。
ある程度はスピードとのトレードオフなので仕方ないかもですが、もう少し横断的に開発していくべきだったなと思っています。
ただ、メンバー全員が責任を持って取り組んでくれたおかげで、誰もメンバーが欠けることなくリプレイスを終えることができました。
あとがき
0 → 1 というより、マイナス → 0 にするフェーズだったのでかなり貴重な経験をさせてもらいました。
エンジニアとしても成長できました。
事業責任者と関わることも多かったので、浮かび上がる課題に対してエンジニアリング以外で解決する方法を学べました。
また、エンジニアという役割上、課題をどう解決していくかという How に目が行きがちですが、そもそも課題や目的は何なのか、はたまたそれは本当に課題なのかという Why の視点を持てるようになったことが良かったです。
おまけ
新旧リプレイス表
| 環境 | 旧 | 新 |
|---|---|---|
| 全体構成 | モノリシック | マイクロサービス |
| サーバー | オンプレ | クラウド(AWS) |
| インフラ構成管理 | 手動 | Terraform, Ansible |
| バックエンド言語 | PHP 5.1 | PHP 7.1 |
| バックエンドフレームワーク | Ethna | Laravel |
| フロントエンド | jQurey | Vue, React |
| DB | MySQL 5.5 | MySQL 5.7(Aurora) |
| バージョン管理 | Subversion | Github |
| メール | オンプレ | SendGrid API |
Google Developers Summit：Progressive Web Appsに行ってきた
少し前に行われたGoogle Developers Summit : Progressive Web Appsに行ってきたので、PWAについて自分なりにまとめたいと思います。
Progressive Web Apps（PWA）とは？
無理やりシンプルに説明すると、今までのWebアプリ（サービス）に、
プッシュ通知やオフラインアクセスなどをできるようにした新しいWebアプリの概念です。
Webアプリでプッシュ通知やオフラインアクセスを使うにはどうするのか？
答え：Service Workerを使う！
Service Worker（SW）とは？
Webページとは別にバックグラウンドで実行されるJavascript環境（API）のことです。
プロキシ的な感覚が近い？と思います。
なので、技術的にはPWAを勉強するというより、
SWを勉強すると表現した方がいいかもしれません。
詳細はこちらを参照。
Service Workerを使うには？
具体的な使い方はこちらを参照。
なお、Service Workerを使うには、SSL化（HTTPS）が必須になります。
SUUMOのPWA導入事例
これは実際にカンファレンスで聞いてきた話です。
SSL化の課題
SUUMOでPWAを導入する際に1番ネックになったのがSSL化で、
かれこれ1年以上かかっているそう（大きな理由はlocalStorage）。。
しかも紙媒体のURL表記が「http」のものもあるので、
「HSTS」を導入する予定とのこと。
Add to Homescreen
ホーム画面にショートカットを追加させる施策です。
スーモに再来訪したら「ホーム画面に追加しませんか？」的なバナーを出して追加を促したそう。
ホーム画面から来た人はCVRが約1.2倍と言っていたので、導入効果はあるもよう。
Offline Cache
利用したことで表示速度が約4倍に。
プッシュ通知
ユーザーが新着案件（賃貸）情報を受け取る設定をしたら、
スマホにプッシュ通知できるような仕組みを検討中とのこと。
その他
ジオフェンシングもそのうちやりたいと話していた気が。
まとめ
スピーカーも話していましたが、ネイティブアプリは色々大変なんですよね。
リリースとアップデートに審査が必要だし、
GoogleとAppleを挟む分、自由じゃないし時間がかかったり。
その点、PWAのようにWebにあるといつでも改修できるし、
各OSに依存しないのでネイティブアプリのデメリットを解消できます。
結構明るい技術だと思うのですが、
今のところブラウザのSafariとMicrosoft Edgeに対応していないようです。
※対応状況はこちらで確認できます。
なので、iOS主流の日本ではすぐすぐ取り入れる技術ではないかもしれませんが、
今後のアプリのトレンドして抑えておく必要はありそうです。
iOSアプリ（9対応）のリリース準備・対応で苦労したこと5つとおまけ
リリースというものは、そう何回もやるもんじゃないので方法を忘れがちです。
覚えている今のうちにメモしておきます。
※ちなみにXcode7を使っています。
1．リリースするための事前準備が意外と多かった
- DistributionタイプのCertificateが必要
- App IDが必要
※ここで出てくるBudle IDとXcode上のBundle Identifierがイコールじゃないとリリースできません
- DistributionタイプのProvisioning Profileが必要
方法はこちらが参考になりました。
2. 1度iTunes ConnectにBuildしたらBuildの値を上げないと再Buildできない
アプリをリリースするにはiTunes ConnectにXcodeからBuildする必要があります。
※方法はこちらを参照。
しかし、Buildし終わってから、
「やっぱりあそこはこうしよう！」って思い立って修正したくなります。
きっとなります。ほぼなります。必ずなります。
その際はXcodeから、
「General」にある「Build」を「1.0.1」のように上げる必要があります。
そうすれば別のBuildとみなしてくれて再度Buildできます。
ちなみにリリース後にアップデートするときは「Version」を上げます。
3.スクリーンショットにAppleの画像などがあると商標違反でリジェクトされる
アプリ申請時には、
アプリの見せ場的なものを載せたスクリーンショットを、
一緒にアップすることになるんですが、
そこにAppleの商標情報があるとリジェクトされます。
今回のアプリは見せ場的なシーンが少なかったので、
作ったアプリのアイコンが写っているホーム画面のキャプチャをアップしたら、
Apple製品のアイコンも載ってしまい怒られましたｗ
4. 「広告表示してないのにAdvertising Identifier使ってるよ」ってリジェクトされた
Advertising Identifier but does not include ad functionality...
「Advertising Identifier」っていうのは広告識別子のことです。
広告タグとかリンクコードの認識で大丈夫だと思います。
iADとか使ってないし、心当たりがなかったのですが、
「nend、i-Mobile、Adstir?」とかは裏で用意してるだけでも引っかかるようです。
※文字列だけでも引っかかりました
これ地味に引っかかる人いるんじゃないですかね？
5. リリース後のApp Storeのリンク作成
通常、PCのiTunes（App Store）からiOSアプリを探そうとすると結構苦労します。
（というかできるのか？）
そんなときは「Link Maker」を使うと簡単に辿り付けますし、URLも発行できます。
検索するときの注意点として、日本の場合は「Store Country」を「Japan」にし、
iOSアプリの場合は「Media Type」を「iOS Apps」に変更する必要があります。
おまけ
実はApp Storeの審査は特急で行うように申請ができます。
※方法はこちらを参照
試しに「Android版」が既にリリースされているので、
早く審査してくれって申請してみたところ、
案の定、却下されましたｗｗ
通常はクリティカルなバグの修正や、
ハロウィンなどのイベントに合わせたアプリじゃないと、速攻で審査してくれないようです。
ご利用は計画的に。
GWちょー暇という非リア充にオススメする7つの名スライド
ゴールデンウィーク暇過ぎる！
という非リア充な方のために、
僕が今まで読んで感動したスライドをまとめました。
本を読むのはちょっと、、
という方にはちょうど良いボリュームだと思います。
グロースハック系
クックパッドのグロースハックについて
クックパッドのグロースハック事例についてです。
30ページくらいから本題です。
君にグロースハックはいらない
マイクロソフトでエバンジェリストをしている馬田さんのスライドです。
始めのうちはスケールさせようとするより、
PMF（プロダクト・マーケット・フィット）が大事だよと言っています。
技術者向け
エンジニアのための経営学
あくまでも、技術（プログラミング） は手段だと言う話です。
技術好きな人ほど読んだ方が良いかも。
UIの話は会議室でするな
17ページに出てくる「関係なさそうな人にも聞こえるくらいの声量で話す」、
これは結構重要だと思う派でして。
何故かと言うと、そうすれば他の人の耳に入って、
何かおかしいことを言った場合orその人の方が詳しい場合、突っ込んでくれるから。
そんなのウルサイから止めてくれとか賛否両論ありそうですが、
新人が多い環境とか、コンセンサスを多く得なければいけない環境には向いていると思います。
WebエンジニアのためのWebサービスデザイン実践講座
エンジニアの人もデザインが出来た方が楽しいよという内容です。
そして、具体的なデザインの考えた方も学べます。
キャリア系
転職基準-スタートアップへの転職を検討するための予備知識
上述した「君にグロースハックはいらない」を書いた馬田さんのスライドです。
この人のスライドは本当にためになるので、他のスライドも読んでみてください。
ちなみに、よくY Combinatorのポールグレアムが登場しますw
私のキャリアチェンジ
最後は、ご存知伊藤直也さんのスライドです。
自分の好きなことが得意なこととは限らないというお話です。
おしまいです。
他に良いスライドあったら教えてくださいm(_ _)m
HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか
- 作者: ベンホロウィッツ
- 出版社/メーカー: 日経BP社
- 発売日: 2015/04/17
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
NEOブログサービス「Medium」でフォローすべき日本語アカウント5つ
ここ最近よく聞くようになったMediumですが、まだまだ英語の記事が多いです。
そこで今回は、日本語でストーリーを書いているアカウントを紹介します。
Mediumとは？
まず初めに、Mediumとは何なのかをザックリ説明します。
既知の人はスルーして次へ行ってください。
Mediumを無理やりシンプルな言葉で説明すると、
新しいカタチの「メディア」や「ブログプラットフォーム」と言えます。
「ブログプラットフォーム」というだけあって、登録すれば誰でも記事（ストーリー）を投稿できます。
Mediumには「Write your response」という特徴的な機能があります。
読んだ記事に対して自分が思ったことを書けるのです。
他には「Recommend」といったリツイートのような機能もあります。
ファウンダーは、元Twitterのエヴァン・ウィリアムズとビズ・ストーンです。
他には、元WIREDのスティーヴン・レヴィなどもジョインしているようです。
おすすめアカウント5つ
さて本題です。
以下の人達は日本語でもストーリーを書いています。
ガンホー、MOVIDAの孫泰蔵さん
元グノシー共同代表の木村新司さん
セカイカメラ、テレパシーの井口尊仁さん
Lean UX監訳者でUX Tokyo主宰の坂田一倫さん
Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)
- 作者: ジェフ・ゴーセルフ,ジョシュ・セイデン,エリック・リース,坂田一倫(監訳),児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/01/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
Medium Japan
Mediumの日本アカウントです。
日本語の記事をレコメンドしてくれます。
ちなみにツイッターアカウントもあります。
まとめ
紹介した人達は、まだ日本に浸透していないにも関わらず、ストーリーを書いているアーリーアダプターなので、さすがに内容も素晴らしく面白いです。
Mediumの読むことに集中できるインタフェースも好きです。
堀江さんとかが書いたら日本にも広まるんですかねー。
インスタグラムの投稿にリンクが付いたら何が起こるか
インスタグラムについて
先にちょっとインスタグラムについて紹介します。
2010年の10月にサービスをスタートさせて、12年の4月にFacebookに10億ドルで買収されました。
当時のFacebookでは過去最高の買収額でした。
※現在ではWhatsAppの約200億ドルが最大。
買収時点での月間アクティブユーザー数は3000万弱でしたが、
2014年12月にはツイッターを上回り3億を超えています。
こう振り返ってみると、ザッカーバーグの先見の明と行動力は凄いですね。
現在のインスタグラムの仕様
- 画像投稿
- ムービー投稿（15秒）
- 投稿にURL（リンク）は載せられない
- プロフィールページのみリンクを載せられる
- 画像をフォロワーにダイレクト送信
- タグ付け、位置情報
- いいね、コメント、ブロック
- タグ&アカウント検索機能
主な機能はこんな感じです。
ちなみに最近のアップデートで、ムービーがVineと同じようにループ再生されるようになりました。
これは凄く正しいと思います。
投稿にリンクが付けられるようになったら何が変わるのか
本題です。
ちょっと前に話題になりましたが、著名人の投稿にスパムコメントが増えています。
芸能人のインスタにスパムコメントが溢れてる... - NAVER まとめ
タレントなどのアカウントは、一般のアカウントと違って多くの人が見ています。
そこを狙って、スパマーは全く関係の無い商品名などを書き込んで宣伝しています。
ここにリンクが付けられるようになるとどうなるでしょうか。
閲覧している人の中には情弱な人もいるので、「オススメしてるし良いかも」と思ってしまい、そのリンクから商品を購入してしまうかもしれません。
次に、そのリンクからコンバージョンしたと計測することが可能になるので、この流れを斡旋する業者が現れます。
そうして、スパムアカウントがどんどん増えていき、インスタグラムのロイヤリティは失われ、ユーザーは減り、サービスとして終わりを迎えてしまいます。
まとめ
僕が働いているのは広告業界なので、会社としてはウェルカムなのかもしれませんが、個人的には嫌ですね。
上述したのは最悪の場合のシナリオです。
ザッカーバーグ自体は広告が嫌いですし、今はFacebook上での広告収入が上手くいっているので、当分は無いと考えますが、数年後はどうなっているか分かりません。
もし、投稿やコメントにリンクを導入するなら、相当上手く設計しないとキツい気がします。
CentOS7でPHPとか動かすところまで構築するのに使ったコマンドまとめ
こういったインフラ周りは日頃触らず忘れやすいので、自分の備忘録としてまとめておきます。
環境はAmazon EC2です。
CentOS6.xと7の主な変更点
- 「service」コマンドと「chkconfig」コマンドが、「systemctl」コマンドに統合
- 「iptables」が「firewalld」に変更
- 「ntpd」が「chronyd」に変更
- 「ifconfig」が「ip」コマンドに変更
ユーザーを「centos」から「root」に切り替える方法
CentOS7の場合、初期ユーザが「centos」でした。
「root」になるには新しくパスワードを作成する必要があるようです。
Apachのインストール
「service」コマンドは「systemctl」コマンドに変わったので、以下になります。
chkconfig -listの代わりに
以下のコマンドで、自動起動設定を一覧で確認出来ます。
firewall（iptables）の設定
iptablesもfirewallに変わったので、設定の方法が異なります。
時刻合わせ
PHP周りで使いそうなものをインストール
この辺りは、CentOS6.xと変わりません。
PHPのバージョンは5.4がインストールされました。
以下でもできます↓（むしろこっちの方がスマート）
PEARをインストール
使うと思われるものをインストール。
postfix （デフォで入ってる模様）の設定
メールを送受信したい場合は、postfixの設定を変更しましょう。
おまけ
上述したコマンドは全てGitHub Gistを使って埋め込んでいるのですが、
せかせかと書いていたら突然BANされました↓
更新しすぎてスパマーだと思われたのが原因のようです。
しかし、Contactページから問い合わせたらすぐ直してもらえました。
件名：I'm not a spammer.
本文：Please reinstated my gist account.
みなさんも更新のし過ぎにはお気をつけください。
Code Complete 第2版 上 完全なプログラミングを目指して
- 作者: スティーブマコネル
- 出版社/メーカー: 日経BP社
- 発売日: 2014/04/02
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
