Noteビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。catsはじめまして、サーバーサイド開発部(Scala)の阿部(rabe1028)です。業務ではScalaを書いていますが、一番好きな言語はRustです。昨年から今年の頭にかけて実施したシステム移行のお話をチームメンバーを代表して書こうと思います。*1今回の移行対象となるシステムについてChatworkでは、モバイル端末にプッシュ通知を送信しています。Chatworkユーザーの利便性向上のために、モバイルプッシュ通知にChatworkに投稿したメッセージ本文を載せる機能開発を行うことが決定しました。blog-ja.chatwork.comChatworkは2011年にリリースされ、リリース時からモバイル端末へのプッシュ通知の機能がありました。PHPで実装され、11年間継続的に開発・運用されています。既存システムを確認し新規機能開発が行えるか検討したところ、当時の開発リソースだとPHPで実装することが困難であったため、まず対象となるシステムをPHPからScalaに移行することになりました。PHPからScalaに移行しなければならないのかChatworkでメッセージを投稿するとき、色々なメッセージの記法を利用することができます。記法変換せずに、そのまま通知に載せてしまうと、ユーザーは画面で見たときのメッセージと違う印象を受けてしまうと思います。メッセージ記法変換の一例この問題を防ぐためには、Chatwork記法を解析し、各種Tokenを変換する必要があります。そちらを利用するために、PHPからScalaへのシステム移行を実施する運びとなりました。通知全体の流れChatworkでは、グループチャット内での各種操作やコンタクト周りの操作が行われた時にモバイル端末へ通知を送信しています。各種イベント発生時にSQSに積むChatworkの通知イベントは、メッセージの追加・編集、タスクの追加・編集・完了のようなグループチャット内のイベントや、コンタクト追加などアカウントに紐づくイベントなどがあります。SNSを介してユーザーの持つスマートフォンに通知を送ります本文の表示機能に対応させるためには、3の処理を担当するバッチを移行することとなりました。pegasus-irisと記載します)へ無停止で移行するために、以下のようなフローで移行を実施する計画となりました。Queueを用意する開発したアプリケーションを動作させるイベント送信元を改修し、新しいQueueに送られるようにする3のリリースのタイミングから、新規開発したアプリケーションにイベントが流れ始めます。移行段階のシステム構成図これにより、イベント送信元で送るSQSを制御することで、部分的に移行先システムにイベントを流すことができるようになります。Applicationを開発するためのScalaライブラリを選定する必要があります。Streamを扱うライブラリとして、今回は以下の3つが候補に上がっていました。Streamsfs2ZIO(ZStream)以上の3つについて、いくつかの観点で比較検討しました。検討軸は以下を用いました。projectはScala3のサポートも進んでおり、検討当時はZIOのメジャーアップデート前でタイミングが悪かったこと、ライブラリの依存を局所的にしたかったこと、そして、社内でまだ採用実績のないライブラリを使ってみたい!ということでfs2を採用しました。開発手順PHPからScalaに実装するにあたり、全く同じ処理を書き写すのではなく、PHPで各所に散らばったドメイン知識を集約して書き直す方式を取りました。そのため以下のように複数回ドメイン分析を実施しています。分析したドメインに基づいて実装する2,3を繰り返す今回のシステム移行では、ドメインモデル図が5回ほど作り直されています。作り直した理由としては以下のようなものがあります。実装していって、より適切な分割が思いついた最初のドメインモデル図では、既存の処理として不足している部分があったPHPの元の実装だと、ドメインに該当しそうな処理が各所に散らばっており、実装時に後から見つかった処理がドメインにいた方が適切であったなど苦戦したところ余談ですが、ちょっと開発時に悩んだポイントについて共有しようと思います。Shutdownの機構がないため、処理中にStreamがterminateされないようにする必要があります。Streamを安全に停止させることができます。これをサポートするために以下のような関数を作成して、Sourceからのconsumeを止められるようにしています。falseを設定すれば、consumeが停止するようになっています。SQSにデータを「書き込む」側のシステムです。読み込み側のシステムであれば、移行前後のシステムのレスポンスを比較して機能が問題ないか担保できますが、今回は書き込み側のシステムなので、その手段は利用できません。ストリームアプリケーションのデータを比較するとなると、Streamに流れてきたイベント、移行前後のシステムから出力されたイベント双方を記録し、同じ入力のイベント同士を比較するというシステムを別途作成しなければなりません。このようなシステムを設計し、開発するのは大変であったので、今回はモバイルプッシュ通知の網羅テストをクリアすることで、機能要件を満たしているか確認しました。網羅試験が終わったので、あとはリリースのみです。リリースの際は、移行前のシステムと移行後のシステムの間でSQSに流す割合を段階的に変化させることでカナリアリリースを行います。移行が完了したら、既存の不要なコードのお掃除です。移行後の動きシステム移行が無事完了しましたが、今回はこれが完遂すべき目的ではなく、本来やりたい「プッシュ通知本文表示」の前段階です。この後にプッシュ通知本文表示のPJで機能開発を実施しました。その話は、また機会があれば書こうかなあと思います。*1:一緒に移行を担当したチームメンバーには最後までお世話になりました。ありがとうございました。アプリケーションの開発運用をお...2022-10-05Akkaのライセンス変更についてこんにちは、かとじゅんです。2022』...2022-03-25ChatworkはPHPエンジニアの採用をより強化していきます、というお話。@Chatwork_devメンバーid:cw-oritaid:okuzawatsid:d-hayashiid:shibe23id:cw-jeromechaid:cw-araiid:tinpayid:cw-sakamotoid:rabe1028id:cw-suetakeid:lmdexprid:cw-shinyaid:cw-takaseid:cw-niinumaid:j5ik2oid:tan-yukiid:yamakenji24id:yoshiyoshifujiiid:cw-ayumitakahashiid:cw-furuyaid:kaz3284id:cw-ozakiid:cw-nishikawaid:daiksyid:tasuku43id:louvre2489id:sykt13id:yamatomo73id:cw-kasugaid:cw-mottyid:cw-nishiguchiid:s12btid:cw-sayamaid:cw-moriyaid:cw-makotoikedaid:cw-yoheihayashiid:wakakumaid:cw-sakaguchiid:cw-matsubaid:ymgnid:shige0501id:nottegraid:shinharadid:eielid:cw-michihiroid:crossroad0201id:cw-miyashitaid:agoetcid:at-akaid:cw-chibaid:tenslerid:cw-akatsuid:cw-kajiwaraid:cw-otakeid:TomokoNishinaid:cw-tanakaid:cw-hayashiid:cw-marikoid:cw-shinmenid:cw-masakiid:cw-hayama最新記事モバイルアプリ開発チーム、カンバンはじめました。(1)引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。