読者です 読者をやめる 読者になる 読者になる

ボクココ

サービス開発を成功させるまでの歩み

外部サービスの API を利用する上で注意すべきこと

スタートアップ

ども、@kimihom です。

どうしてもスタートアップだと最新技術で勝負するわけで、最新技術であればあるほどその API の仕様変更の頻度が多くなる。これによりトラブルになることが多々ある。実際、最近私も経験してしまった。

この手の一番厄介なところは、テスト環境でいくらテストしてもいきなり本番で問題が発生する可能性があるということ。つまり外部サービスの気分次第で私たちが夜叩き起こされる可能性があるということでもある。これはなかなか辛い。かといって外部サービスを使わない選択肢を選ぶと、それはそれで開発コストのかかる荊の道が待っている。両者のメリット・デメリットをしっかりと考えなければならない。

今回は外部サービスを使っている時に注意したいことを考えてみよう。

最新情報は必ずフォローする

しっかりとした Web サービスであれば、 Twitter や Facebook などの SNS を始め、メールなどで告知をあらかじめしてくれる。最新情報を必ずキャッチしてエラーが起きないよう常にアンテナをはりつづけよう。それすらもしないで運営に問い合わせるようなことをしてはいけない。外部サービスAPIを使ってサービスを提供する者ならだれでもやらなきゃいけないことだ。

逆に最新情報を発信していないような外部サービスはかなり危険だ。いきなり変わっていきなり問題が起きるようなことが起こりうる。外部サービスのAPIを使う上で情報発信をしているかというのはとても重要な判断基準になる。

外部APIのどんな仕様変更やエラーが起きても、被害が最小限にとどまるようにする

外部サービスの予告ありリリースならその瞬間を気をつけて待ってればいいのだが、マイナーな仕様変更とかで特にアナウンスなしで勝手に変わり、それがたまたま自分たちの実装に影響が出ることもある。そのため、どんなに外部サービスのAPIの最新情報を追っていたとしてもトラブルを100%防ぐことは不可能だ。

外部サービスを使うならトラブルが起きること前提で物事を考え、その時に被害が最小限に収まるよう努めなければならない。

具体的には例えば JSON が帰ってくるようなAPIがあった時に、HTTPステータスコード2xxだけの成功したレスポンスを書くのではなく、それ以外の例えばサーバーエラーである5xx系のレスポンスも深く考えてコードを実装するようにしよう。5xxレスポンスが帰ってきた時に、ユーザーにお知らせするのがいいのか、エラーが起きてもなんとか裏側でなんとかできるようにするのか、そもそもリクエストをしなかったことにするのか、など最適な方法でエラーハンドリングを実装しよう。

例えば A を実行した後 Bを実行するようなプログラムがある場合、 A が失敗したとしても Bを実行させられるようなコードをあらかじめ考えておくことは重要だ。 B すらも動かないとシステムに深く影響が出てしまうようなコードを私は以前実装してしまい、痛い思いをしてしまった。

この類の問題は普通にテストしてても問題ないのだ。だからこそ、「このAPIでエラーが来た時どうなるだろう」という予測とその対応が必要になる。なかなか滅多に起きない問題なんだけど、しっかりとしたエラーハンドリングをしないと起きた時に深刻な問題を起こすことになるだろう。

問題が解決できない場合に備えてすぐに連絡できる手段を持つ

問題が発生し、しかも治すことができない場合、最悪サービスが1日以上止まるといった可能性もありうる。こんな状況が起きたら真っ青だ。

エラーが起きたらすぐにそのサービスの中の人と連絡が取れるようにしておこう。電話番号が一番理想だが、直通のメールアドレスなども良いだろう。とにかく最優先でやって欲しい時にだけ使う最後の手段を持っているかいないかは日々の運用の安心材料にもなる。

プレミアムサポートといったプランで別料金かかるようなサービスもある。規模が大きくなってトラブルに敏感になったら、プレミアムサポートプランの契約を検討したほうがいいだろう。給料で誰かを雇うよりよっぽど安心できる。ケチっていいところと良くないところを見極めるのも重要なところだ。スタートアップならお金をあまりかけずに始めるってのは大前提だけど、それなりに稼げるようになってきたら自分の給料にするよりこうしたことにお金をまず払い、安心できる体制を整える方が先決ではないだろうか。

終わりに

今回の記事は実際に私が痛い目を見て感じたことだ。特に最後のサポートにお金をかけるってのはスタートアップだとなかなかできずに勇気のいる行動だと思う(実際私もそこまでできていない)。それでも本当にサービス停止がクリティカルになってきたら、ぜひ本記事を思い浮かべてしっかりとしたトラブル対策をできるよう整えておきたいところだ。

より安心して眠れることのできるエンジニアが増えることを祈るばかりである。