新たなAAA：API、認証、可用性

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

もうお気づきかもしれませんが、そうです。私はPokémon Goをプレイしている、いわゆるあの手の人間です。もっとも、最近よくあるように、Pokémon Goをプレイしていないこともあります。これは困ったことです。末っ子もプレイできないからです。実は2人ともGoogleアカウントではなくPokémon Trainer Club (PTC)アカウントを使っているため、ログインできません。

これは重要な点です。私たち2人は「認証」できず、ログインしてプレイできないことに不満を募らせていますが、Googleアカウントを選んだ夫には、同じ問題が起きていないからです。

そこで、提供するアプリにかかわらず、あらゆる企業にとって重要な技術上の懸念事項を掘り下げてみました。その懸念は、新たなAAA、すなわちAPI、認証、可用性をめぐるものです。

興味深いことに、この探求のきっかけは、Pokémon GoでのPokémonの追跡に関するForbesの記事を読んだことでした。そう、あのForbesです。それほど大きな話題だったのです。いずれにせよ、そこから次々と別の記事を読むことになり、そのうちの1つでは、追跡機能が（少なくとも当初）動作しなかったのは、ゲームのアップデート時にNianticのサーバーへ送信する追跡リクエストからAPIキーが誤って抜け落ちたためではないかと推測していました。

実際にそうだったかどうかはともかく、このようなミスがあれば、確かにAPIは機能しなくなります。しかし、どうしても腑に落ちなかったのは、PTCアカウントではログインしてプレイできないのに、Googleアカウントに切り替えるといとも簡単にログインできたのはなぜか、ということです。

APIと認証の関係

そこで、githubを調べ、Pokémon GoのAPIを詳しく見てみました（私はJavaのほうが好みですが、Pythonもあるので、好きなだけ試してみてください）。そして、それでようやく「なるほど」とひらめきました。実は、これらのリポジトリにあるほぼすべてのAPI呼び出しが、同じ例外を処理しています。LoginFailedExceptionです。

つまり、近くにいるPokémonを探すだけの単純な呼び出しでも、LoginFailedExceptionが発生する可能性があります。

これは、実のところそれほど意外なことではありません。モノリシックなWebアプリケーションでは、多くの場合、セッションを使用して認証済みユーザーを追跡します。通常は、アプリケーションが他の処理を行う前に確認するセッションIDなどのトークンを含むCookieを使用します（ここまでお読みの方ならお分かりのとおり、これはステートフルなアーキテクチャです）。APIもそれほど違いはありません。各API呼び出しでは、呼び出し元のアプリケーション（ユーザー）に、そもそもその呼び出しを行う権限があることを確認する手段が必要です。つまり、「ログイン」している必要があります。

現在、APIではこの目的を達成するためにAPIキーがよく使用されます。通常、呼び出しが承認されていることを確認するため、キーはユーザープロファイルと照合されます。これは、ステートレスアーキテクチャでは呼び出しのたびに行われます。この方式を採用する理由はいくつかあり、呼び出しをレート制限できることもその1つです。これは非常に重要です。Apigee’s State of APIs 2016レポートによると、APIの68%がクォータ管理（レート制限、メータリングなどとも呼ばれます）を利用していました。この仕組みを実現するには、まず過去1分間、1時間、1日あたりの呼び出し回数を把握する必要があります。そのため、ユーザーがデータを操作し、一定期間内に許可される呼び出し回数をアプリケーションに増やさせることができないよう、安全な場所で追跡する必要があります。

つまり、APIではステータスと認可を検証し、場合によってはレート制限も適用する必要があるため、認証インフラに大きな負荷がかかる可能性があります。これは非常に多くの処理を伴います。

しかし、依然として従来型に偏りがちなアプリケーションアーキテクチャの考え方では、こうした追加の呼び出しがキャパシティに及ぼす影響が考慮されていません。検証と認可のための追加呼び出しは、セッションを「更新」する目的で定期的に行う場合でも、認証インフラに大きな負荷をかけます。しかも、ログインを支えているのと同じ認証インフラです。これは、ユーザーあたりの接続数に関するブラウザの上限が2から8に引き上げられたときに見られた負荷と同様です。その結果、1人のユーザーがアプリケーションへのアクセスに消費するリソースは8倍になりました。同様に、API呼び出しごとの認可に依存するアプリケーションのキャパシティ要件を検討する際は、計算を行い、個々のユーザーが何倍のリソースを消費するのかを把握する必要があります。

これを怠ると、過負荷に陥ったログインサービスが、どうしても捕まえたいピカチュウとの間に立ちはだかり、8歳の子どもたちを怒らせることになります（もちろん、Loriも怒ります）。

可用性の確保に不可欠なIDおよびアクセス管理のスケーリング

アイデンティティとアクセスは、アプリケーションに不可欠なサービスです。過去2年間のF5のアプリケーションデリバリの現状調査では、その重要性が高まっています。詳しくはまだ明かせませんが、2017年のデータでは、アイデンティティフェデレーションとアプリケーションアクセス制御の両方ですでに増加が見られます。その要因はアプリケーションだけではありません。モノの存在も要因です。より多くのモノやユーザー、そしてAPIを使用してバックエンドアプリケーションと連携するより多くのアプリケーションをサポートするため、アイデンティティサービスインフラストラクチャ全体を幅広くスケールアウトする必要性が高まっています。

可用性は、多くの場合、ダウンタイムの測定値だけに基づいて判断されます。 サーバーが稼働し、正常に動作していれば、利用可能と見なされます。これは内側から外側を見る視点です。しかし、セキュリティと同様に、この測定の視点を逆転させ、外側から内側を見る必要があります。キャパシティも重要であり、単に「稼働中」で「利用可能」なだけでは不十分です。サービスを利用したいすべての人が「稼働中」で「利用可能」な状態でなければなりません。つまり、Pythonスクリプトの実行速度に合わせてスケールできる必要があります。

また、APIが提供する機能を実際に実装している各種バックエンドサービス間の関係を把握することも必要です。アイデンティティおよびアクセスサービスは、実際のアプリケーション自体と同様に、可用性にとって極めて重要です。可用性もセキュリティと同じく、最も弱い部分によって決まります。アイデンティティサービスに、アプリケーションの他の部分と同等のスケーラビリティがない場合（API呼び出しごとに認証するモデルでは、それ以上のスケーラビリティが必要です）、内部のすべてのダッシュボードが「グリーン」を示していても、可用性が重大な問題となります。

外部から見れば、文字どおりにも比喩的にも「赤」と判定されているからです。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事