デバッグのスピードアップと省力化で開発チームの負担を減らし、ビジネスを開発面で支えるRookout
Rookoutの画期的な「止まらないブレークポイント」は、開発チームにとって強力な武器であり、継続的開発とデプロイメントを途切れさせることなく、新機能の提供にフォーカスさせてくれます。実際の開発現場からの声がそれを証明しています。この記事では、Rookoutを導入済みのユーザー企業の成功事例3点を要約してご紹介します。
成功事例記事
Rewire
「 500回分のデバッグコードの追加・削除作業と本番投入作業を短縮！ 」Rewire は、イスラエルやヨーロッパの移住労働者に低コストのオンライン国際送金サービスを提供するフィンテック企業です。
Rewire Inc.ホームページ（https://www.rewire.com/）
金融サービスの提供においては、リモートかつ分散型のアーキテクチャーで構築されたシステムの開発・運用を、データのセキュアな取り扱いや保管ならびにコンプライアンスの遵守といった条件をクリアした上でおこなう必要があります。障害発生時には、原因究明のためにデバッグコードや監視メトリクスを追加したり、ライブプロセスにデバッガーや追跡メソッドをアタッチしたり、ローカルマシンで現象の再現を試みたりすることが通常で、多くの場合は顧客からのHTTPリクエストボディの特定が焦点となっていました。しかし、たとえリクエストボディ取得のためだけであってもデバッグコードの追加とそのデプロイメントは大げさで時間のかかるプロセスで、そのために毎回開発チーム全体の生産性がゼロ以下になるだけでなく、ダウンタイムを増やす選択は金融サービスとしてあり得ません。
そこでRewireの開発チームはRookoutを採用し、わずか1日足らずで62のアプリケーションインスタンスすべてにRookout SDKをデプロイ、すぐに本番環境のアプリケーションからデータを収集してその動作を把握できるようになりました。それから6か月で500以上の止まらないブレークポイントが作成されています。これはつまり、500回分のデバッグコードの追加と本番投入作業だけでなく、500回分のデバッグコードの削除と本番投入作業もせずに済んだということです。
開発チームはデバッグのためのリリースを本番環境に投入することなく、ソースコードに一切手を加えずに迅速に障害の原因究明ができるようになったのです。結果としてMTTR（平均復旧時間）も大幅に短縮されました。さらに、本番環境でのライブデバッグが可能になったため、開発環境では再現させにくいレアなバグやクライアント環境に依存するエッジケースの場合でも、止まらないブレークポイントを入れるだけで原因究明に必要なデータを得られるようになったのです。また、バグの再現やデバッグにおける不確定要素が大幅に減ったため、自信を持って高頻度で新機能をリリースできるようになりました。
～ RookoutはRewireのサービス復元時間を最小限に抑えます ～
ユーザーのコメント：「リクエスト1,000回のうち1回しか起きないようなレアなバグでも、本番環境で発生条件を再現できさえすれば、Rookoutでデータを取得することで原因がわかります」
Otonomo
「 止まらないブレークポイント”でクライアント側の設定を遠隔で変更！？ 」Otonomoは、ネット接続された自動車の各種センサーからデータを取得して集約する、コネクテッドカーに特化したデータプラットフォームとマーケットプレイスを提供しています。
Otonomo Incホームページ（https://otonomo.io/）
Otonomoの開発チームもまた、デバッグコードや監視メトリクスを追加したり、ライブプロセスにPDB/GDBデバッガーをアタッチしたり、ローカルマシンでバグを再現する「従来のやり方」でデバッグをしていました。しかしそのたびに開発環境、ステージング環境、本番環境のすべてを通してこの時間のかかる一連のサイクルを回すことは、チームにのしかかる多大な負荷となります。必要なのは、本番環境を止めることなく、原因をより直接的かつ迅速に特定して対処できるソリューションでした。
そこでチームはRookoutをステージングと本番環境に導入することで、デバッグのたびにデプロイメントサイクルを回す必要を最小限にとどめ、大幅な時間短縮を実現することができました。さまざまな種類の機器と連携してデータを集約するOtonomoにとって、Rookoutはシステムとクライアント機器とのインテグレーションにも効力を発揮します。機器が正しいリクエストを発しているかどうかを止まらないブレークポイントで確認しながらクライアント側の設定を、時には遠隔で変えて原因を特定することができるからです。
～ RookoutはOtonomo社のデバッグ時間を大幅削減 ～
ユーザーのコメント：「最大のメリットは、システムが”ライブ”のまま障害の原因を把握できることです。障害の切り分けのために何時間もかけてすべての組み合わせをテストするのではなく、正しい場所にブレークポイントを入れるだけ。ほんの数分です」
Eagle.io
「 障害対応にかかっていた時間を83%以上も短縮！！ 」Eagle.io は、 環境センサーなど無数のIoTデバイスからリアルタイムデータを取得して分析可能なかたちに集約し、価値のあるインサイトに変換するIoTデータプラットフォームを提供しています。
Argos.io Pty Ltd.社ホームページ（https://eagle.io/）
Eagle.ioもまた従来のやり方でデバッグをおこなっていましたが、アプリをモダンなコンテナベースの設計に刷新したときに壁に突き当たりました。それまでのモノリス型のシステムのときよりも動作の把握が難しくなり、デバッグやトラブルシューティングのためには複数のEC2インスタンスからさまざまなデータを集めて分析しなければならず、さらに長い時間がかかるようになったのです。また、多様なIoTデバイスと接続する本番環境でのバグ動作を、IoT特有の不安定な接続状況なども含めてローカルの開発環境で再現することも不可能に近い難題で、顧客からの障害報告への対応にはどうしても長い時間がかかっていました。従来のやり方では、デバッグコードが的を外れていたり、パフォーマンス監視ツール（APM）が捕捉しておらずトレースにも残らない現象の場合、打つ手がありませんでした。
そこでEagle.ioはRookoutを採用し、結果としてそれまで障害対応にかかっていた時間を83%以上も短縮することができました。Eagle.ioにとって特に重要だったのは、ローカルの開発環境で現象の再現に苦労する必要も、デバッグコードを追加して再デプロイメントすることもなく、ユーザーが実際に使っている状況下でリアルな本番環境のデータを取得できるところでした。
～ デバッグとトラブルシューティングの時間を数時間から数分に高速化する必要があった ～
ユーザーのコメント：「お客さまから障害報告を受けると、私たちは関連がありそうないくつかの該当箇所に止まらないブレークポイントを設置し、お客さまに現象を再現するように依頼します。そして上がってくるデータを観察することで、問題を絞り込むのです。その原因がコードのバグであっても、それ以外のユーザー特有の環境や状況であっても、すばやくトラブルシューティングできるんです」
今回の掲載企業の他にも多くの企業がRookoutを利用しています。詳細は、Rookout社ホームページ（https://www.rookout.com/customer-success）でご覧頂けます。
