新しいAAA: API、認証、可用性
皆さんは、私が Pokémon Go をプレイしている人の一人であることにお気づきかもしれません。 あるいは、最近よくあることですが、ポケモンGOをプレイしないことです。 それは困ったことです。なぜなら、末っ子もプレイできないということです。というのも、私たちは 2 人とも Google アカウントではなく、ポケモン トレーナー クラブ (PTC) アカウントを使ってプレイしていることが判明し、ログインできないからです。
これは重要なことです。なぜなら、私たち 2 人は「認証」できずログインしてプレイできないことにイライラしている一方で、夫は Google アカウントを使用することを選択し、同じ問題は発生していないからです。
その結果、私は、リリースするアプリに関係なく、すべての企業に当てはまるはずの技術的な懸念事項を詳しく調べるようになりました。 その懸念は、新しい AAA (API、認証、可用性) を中心に展開されます。
興味深いことに、この探求は、私がポケモン ゴーでポケモンを追跡することに関するフォーブスの記事を読んでいたときに始まりました。 はい、フォーブスです。 そんなに大きいんです。 いずれにせよ、それが別の記事、さらに別の記事につながり、そのうちの 1 つは、追跡が (少なくとも最初は) 機能しなかった理由は、ゲームのアップデートで API キーが Niantic のサーバーへの追跡呼び出しから誤って除外されたためだと推測していました。
これが事実であるかどうかにかかわらず、このような失礼は確かに API を壊すことになります。 しかし、私が何度も考えたのは、 PTC アカウントにログインしてプレイできないのに、なぜ Google アカウントに切り替えて簡単にログインできるのか、ということでした。
API認証接続
それで、私は github を調べ回り、Pokémon Go API をざっと調べてみました (私はJava の方が好きですが、 Pythonもあります、どうぞ)。そして、ついに「なるほど」と気づいたのです。 これらのリポジトリ内のほぼすべての API 呼び出しは同じ例外を処理します。 ログイン失敗例外。
つまり、近くのポケモンを見つけるための単純な呼び出しでも、 LoginFailedExceptionが発生する可能性があります。
それは本当にそれほど驚くべきことではありません。 モノリシック Web アプリケーションは、多くの場合、セッションを介して認証されたユーザーを追跡します。これは、アプリケーションが実際に何かを行う前にチェックするセッション ID またはその他のトークンを含むCookieを意味します (これを理解している方のために説明すると、これはステートフルアーキテクチャです)。 API もそれほど違いはなく、各 API 呼び出しには、呼び出し元のアプリケーション (ユーザー) が実際に呼び出しを行う権限を持っていることを確認する方法が必要です。 「ログイン」する必要があります。
現在、API ではこれを実現するために API キーがよく使用されます。 通常、呼び出しが承認されていることを確認するために、キーはユーザー プロファイルと照合されます。 すべての呼び出し (ステートレスアーキテクチャ内)。 このような決定には、通話のレート制限が可能であることなど、さまざまな理由があります。 それは大きな問題です。 Apigee の 2016 年 API 状況レポートでは、API の 68% がクォータ管理 (レート制限、メータリングなどとも呼ばれる) を利用していると述べています。この技術的なトリックを実行するには、まず過去 1 分/1 時間/1 日に何回呼び出しが行われたかを把握する必要があり、そのため、安全な場所で追跡する必要があります (ユーザーが操作して、アプリケーションを騙して一定期間あたりの呼び出し回数を増やすことができないようにするため)。
言い換えれば、API はステータスや承認を検証し、レート制限を適用する可能性があるため、認証インフラストラクチャに大きな負担をかける可能性があります。 それは大変な作業ですね。
しかし、多くの場合、依然として従来のアプリ アーキテクチャの考え方では、こうした追加の呼び出しが容量に与える影響が考慮されていません。 検証と承認のための追加の呼び出しは、セッションを「更新」するために定期的に行われる場合でも、認証インフラストラクチャにかなりの負荷をかけることになります。 ログインをサポートしているのと同じ認証インフラストラクチャ。 これは、ユーザーあたりのブラウザ接続制限が 2 から 8 に増加したときに見られたのと同じ種類のストレスです。 1 人のユーザーがアプリケーションにアクセスするために 8 倍のリソースを消費するようになりました。 同様に、API 呼び出しごとに承認を必要とするアプリの容量ニーズを検討する場合、計算を行って、個々のユーザーがさらに何 X を消費するかを把握する必要があります。
そうしないと、ログイン サービスが過負荷になり、必死に捕まえたいピカチュウと 8 歳児 (そしてロリスも) の間に立ちはだかることになり、怒り狂うことになります。
スケーリングIDと可用性にとって重要なA
ID とアクセスは重要なアプリ サービスです。 過去 2 年間のアプリケーション配信の現状に関する調査で、その重要性が高まっていることがわかってきました。詳細を明かすことはできませんが、2017 年のデータではすでに、アイデンティティ フェデレーションとアプリケーション アクセス制御の両方で増加が見られます。 これはアプリだけの問題ではなく、モノの問題でもあります。API を使用してバックエンド アプリケーションとやり取りする、より多くのモノ、より多くのユーザー、より多くのアプリをサポートするために、アイデンティティ サービス インフラストラクチャ全体を拡張する必要性が高まっています。
可用性は、多くの場合、ダウンタイムの測定のみに基づきます。 サーバーが稼働していて正常に動作している場合は、利用可能です。 それは内側から外側への視点です。 しかし、セキュリティと同様に、その測定を逆にして、外側から内側に見る必要があります。 容量は重要であり、単に「稼働中」かつ「利用可能」であるだけでは十分ではありません。 サービスは、それを利用するすべての人にとって「稼働」し「利用可能」である必要があります。 つまり、Python スクリプトが実行できる速度に合わせてスケーリングするということです。
また、API によって提供される機能を実際に実装するさまざまなバックエンド サービス間の関係を理解することも意味します。 アイデンティティおよびアクセス サービスは、実際のアプリケーション自体と同様に可用性にとって重要です。 セキュリティと同様に、可用性もその最も弱い部分によってのみ決まります。 また、アイデンティティ サービスがアプリケーションの他の部分ほどスケーラブルでない場合 (または、モデルが API 呼び出しごとの認証である場合は、よりスケーラブルでない場合)、すべてのダッシュボードの内部が「緑」であっても、可用性が重大な問題となることがわかります。
なぜなら、外から見ると「赤」に見えるからです。 文字通りにも比喩的にも。