Findy社主催のアーキテクチャを突き詰める Online Conferenceにて登壇してきました
こんにちは。スリーシェイクの手塚です。
自己紹介や何やってる人か気になる方は以下をご参照いただけますと幸いです。
Findy社主催のアーキテクチャを突き詰める Online Conferenceにて登壇してきました。
参加者数は2,700名を超えのビッグイベントになっており、久々の技術系の内容ということもあって少し緊張しました。
自分自身の備忘録的にも当日登壇した内容を掻い摘んで紹介したいと思います。
「Reckoner」 のサービス概要と特徴について
アーキテクチャを中心にしたイベントということで、今回はスリーシェイクが提供するクラウド型のデータ連携ツール「Reckoner」のアーキテクチャ改変にまつわる話をさせていただきました。
細かい内容はスライドをご覧いただきたいのですが、サービスの性質としてのポイントは、少量でリアルタイム性が必要な処理と大規模なデータ処理の両方が求められる点になっています（めちゃ大変）。
現行アーキテクチャの課題と技術的負債
現行のアーキテクチャでは、以下の課題がありました。1点目は弊サービス特有のものかなとは思いますが、2点目のコスト面の課題というのはスタートアップとしてはあるあるで、立ち上げ当初はあまり深く考えられていなかったりする箇所でもあるかなと思います。
実際、SREの技術支援をしていた際に様々なスタートアップのインフラを見てきましたが、その傾向が強い会社も多かったように思います。
一挙両得の新アーキテクチャの実現と今後の展望
課題解決のために新アーキテクチャへの移行に着手始めたのですが、前提として以下の3ポイントを重要視しました。
本記事では3つめの部分について話せればと思います。
今回アーキテクチャのリプレイスにあたって非常に悩ましかった点が、コアコンポーネントをどのように管理するかというところにあり、選択肢としては以下の3つが考えられました。
現行のままでは要件不足のため、既存利用しているOSSにコミットして改修を行う
フルスクラッチで自作する
Public Cloudのマネージドサービスの活用
結果的に今回のリプレイスでは2のフルスクラッチで自作する方向で進めることになったのですが、観点としては影響範囲と対象コンポーネントの立ち位置というところにありました。
特に迷った点が、Public Cloudのマネージドサービスの活用との比較です。基本的な思想としては運用負荷や開発工数を考慮するとクラウドのマネージドサービスの活用は積極的にすべきだと思っています。一方で、マネージドサービスに依存することによってサービス停止による影響があった場合にお手上げ状態になってしまいます。それだけならまだ良いのですが、マネージドサービスの場合、サービス自体の改変や仕様変更が発生するケースがあり（それもユーザーに事前通知されることなく行われる場合もあります）、私自身もそれ起因の障害発生で苦労したことがありました。その中でもリリースしたてのサービスとなると、そのリスクはより高くなるのかなと思っています。
Public Cloudを利用する際にはSLAが設定されていたり、責任共有モデルなどもありますが、果たしてどういう責任が共有されるのかは意識しなければいけません。特にサービス選定・アーキテクチャ設計をする際には慎重に選択していかないといけないのかなと思っています。
教訓とまとめ
最後のスライドは個人的にテンションの上がる本である「Amp It Up」から引用させていただきました。
私自身はエンジニアから事業運営をする立場に変わってきましたが、サービスの成長に伴い、アーキテクチャの重要性について日々痛感しています。
実際、サービス開発をしていると技術的負債なども色々と出てくると思います。
それに対してリスペクトを持って、歩み寄っていくということは凄く重要なことだと思っています。
そんな思いを込めて最後のまとめを書かせて頂きました。
何かしらで皆様の参考になればと思います。
Findyに登録するとアーカイブ動画も見れるみたいですので、ぜひご視聴ください。
この記事が気に入ったらサポートをしてみませんか？