通信キャリアならではの急激な需要増加に対処できるスケーラブルなプッシュ通知基盤を構築。クラウド基盤上で⾼いレベルの⾮機能要件に取り組んだプロジェクトの
中⼼メンバーと、サービスイン後に主体的に課題に向き合ったメンバーの⼆⼈に話を伺った。
KDDI様のプッシュ通知基盤をAWS上に構築するプロジェクトに取り組みました。もともとKDDI様が⾃社サーバで構築していたシステムをAWSにマイグレーションしました。プロジェクトがスタートしてから約9ヶ⽉でサービスインしています。その後はサービスイン以降の改善を含めていくつかの対応をしています。
KDDI様のチームに当社のエンジニアが参加し、一緒にシステムの要件や仕様を検討したり、実際に作り込みをしていきました。あとはインフラ作業など、状況に応じて専門スキルのメンバーを増減させながらやっていきました。園田が加わったのはサービスインしてから保守・改善を担当してもらうためでしたね。
まず、通信キャリアのシステムとして「24時間365⽇安定稼働し、かつ⾼負荷時にも遅延なく対応できるようにしなければならない」という要件がありました。そのため、リクエストを分散処理するアーキテクチャにすることは早い段階から判断していました。その他の⼯夫としては、「システム中のボトルネックがチューニング不可能にならないようにしよう」と考えました。
AWSは必要に応じて個別サービスのスケールアップやスケールアウトが可能です。キューサービスの「Amazon SQS」と「AWS ElasticBeanstalk」を組み合わせ、キューの量に応じてプッシュ通知処理がオートスケールしシステム全体の性能が上がるようにしました。細かな機能によっても違いますが、最⼤で5倍ぐらいまでは耐えられるように構成されています。AWSは従量課⾦型ですから、サーバーレスのマネージドサービスとして運⽤することで必要な性能の分だけコストが発⽣するようになっています。
やはり性能要件ですね。AWSが実現している性能や信頼性のサービスレベルと、今回開発しているシステムとして外部に示すサービスレベルには考え方の違いがあり、その折り合いをどうつけるかが苦労しました。
また、非常に多くのスマートフォンが接続してくるシステムですので、試験段階でテスト環境や開発環境で同程度の接続を完全に再現するのは難しいところがあって、「実際にサービスインしてみないと分からない」というところがどうしてもありました。実際にサービスが始まってから想定外の挙動が発生して、その原因を突き止めて解決していくことを繰り返しやっていましたね。1ヶ月ぐらいは解決策を模索していく時期がありました。そこが園田に協力してもらった部分です。
⼤きく分けると⼆つあって、AWS側の仕様変更に伴う改修とKDDI様側のシステムの変更に伴う改修です。1つ⽬のAWS側の仕様変更については、根幹にかなり影響するものだったので設計からプログラムまで、つくったもの全てを⾒直す必要がありました。いままでつくってきたドキュメントやプログラムに問題がないかを⼀つ⼀つ調べて、その後、サービスインまでに⾏ったテストをもう⼀度同じように繰り返して、アプリケーションが正しく動作するかを確認していきました。
2つ目のKDDI様側のシステムの一部変更に伴うものは、KDDI様のシステム部門の方と連携をとってテストをしていきました。
園田は新卒で初めての配属となったのがこのプロジェクトでしたが、テストだけとか実装だけとかの一部分を任せるというよりも、一通りを任せる形にしていましたので、作業の段取りとか、どういうふうにやれば効率的かとかも含めて考えながら取り組んでもらいました。園田は、いわゆる指示待ちくんになることはなくて、とにかく考えてやってみるっていうのをずっと繰り返す執念があったので、プロジェクトの戦力になっていましたし、私もだいぶ助かっていました。
周りにも質問しやすい環境でしたので、自分で考えたり周りに聞いたりしながら、一つ一つできることを増やそうと心がけていました。
テストをした時に作成するテスト結果レポートで、ただ「大丈夫です」ではなく、「ここがこうだからこう大丈夫です」とか「このへんが気になります」とか、自分の何かしらの意志を少しずつですが入れられるようになってきたことですね。ただ頼まれたことをこなすだけじゃなくて、付加的に「こうなるともっといいと思います」みたいな伝えられる力をもっと付けていきたいなと思っています。
チーム内で会社の垣根を越えて形式張らずに声を掛け合うことができたのがよかったと思いますね。園田にとって、いい成長の機会になったと思います。
