Amazon API Gatewayを使用したSAP用APIのデプロイ

この記事は、Amazon Web Services (AWS)のSAPデジタルコンサルタント、KK Ramamoorthyによるものです。

お客様、パートナー、そして従業員は、様々なチャネルによるシームレスかつセキュアなユーザー体験を求めています。例えば、Amazon Alexaのような音声認識デバイスを使用して注文するお客様は、モバイルデバイスでも同じ体験を必要とするでしょう。あるいは、モバイルアプリを使用してトレーニングマニュアルにアクセスしているフィールドテクニシャンは、拡張現実アプリでもこれらのマニュアルにアクセスして表示できる必要があります。

このような統一されたユーザー体験を実現するには、アプリケーションプログラミングインターフェイス (API)が重要な役割を果たします。APIとAPI管理プラットフォームにより、使いやすいドメインドリブンのサービスをアジャイル型で、柔軟性、安全性、拡張性のある方法で公開できます。

API管理プラットフォームは、以下の重要な機能を提供します：

あらゆる規模のパフォーマンス
セキュリティと柔軟性
スロットリングによるトラフィック管理
グローバル展開とエッジキャッシングのサポート
ライフサイクル管理とバージョニング
カナリアデプロイメントのサポート
APIキーの管理
APIアクティビティの監視
複数のコーディング言語でのSDK生成
APIのカタログ化と文書化

Amazon API Gatewayは、フルマネージドで、あらゆる規模で動作し、これらすべての機能を実現するサーバーレスのAPI管理プラットフォームです。API Gatewayは、HTTP(S)エンドポイントに簡単に接続したり、カスタムビジネスロジックを実行するAWS Lambda関数を呼び出すことができます。また、サービスの呼び出しごとにバックエンドシステムと接続する必要がなく、API Gateway内のデータを柔軟にキャッシュできます。これらはAPI Gatewayの機能のほんの一部です。詳細については、AWSウェブサイトのAPI Gatewayを参照してください。

API GatewayとSAP

SAP顧客は、どのようにしてAPI Gatewayのメリットを得られるでしょうか。SAPでは、Open Data Protocol (OData)を使用してRESTベースのサービスを簡単に公開できるSAP Gatewayを提供しています。仮想プライベートクラウド (VPC)内のプライベートサブネットにSAP Gatewayハブシステムをすばやく立ち上げ、Network Load Balancerを通じてAPI Gatewayでセキュアに公開することができます。APIリソースがAPI Gatewayを介して公開された後は、特定のビジネスニーズに応じてさらに細かく調整することができます。例えば、特定のサービスの応答性を強化し、それ以外の場合はローカルでプロキシスルーまたはキャッシュするといったことができます。

Webアプリケーションやモバイルアプリケーションの場合は、AWS AppSyncをAPI Gatewayと組み合わせられます。AWS AppSyncは、データ駆動型のアプリケーション開発を可能にするフルマネージドなサービスです。また、オフラインと競合解決をサポートしています。AWS AppSyncの詳細はこちらを参照してください。

リファレンスアーキテクチャ

このサンプルのリファレンスアーキテクチャは、これらのコンポーネントがどのように連携しているかを示しています。

VPC内のプライベートサブネットには、SAP Gatewayを含むSAPアプリケーションが配置されています。
プライベートサブネットに配置されたNetwork Load Balancerは、SAP GatewayシステムのHTTP(S)ポートに接続し、意図されたすべてのリクエストをプロキシします。簡素化するために、このアーキテクチャでは、SAP Gatewayシステムは一つのAmazon Elastic Compute Cloud (Amazon EC2)インスタンスとして表示しています。ただし、実際には効果的な負荷分散のために複数のアプリケーションサーバーとWebディスパッチャを実装する必要があります。
VPCリンクは、API GatewayとNetwork Load Balancerをセキュアに接続します。これにより、SAPシステムを外部ネットワークに公開することなく、API Gatewayを介してSAPサービスを安全に公開することができます。必要に応じて、API Gatewayで生成され、SAPシステムで信頼されるクライアント証明書を使用することで、サービスをさらに保護することができます。これによって、API GatewayだけがSAP Gatewayのサービスに接続できるようになり、セキュリティのレイヤーが追加されます。
複雑なビジネスロジックの場合、API Gatewayを使用して、VPC内に展開されているLambda関数をトリガーすることができます。
APIが公開されたら、AWS AppSyncを使用してデータドリブンなモバイルとWebアプリケーション開発のためにAPIをさらに抽象化することができます。
公開されたサービスを使用するために、Amazon LexやAWS IoTなどの他のAWSサービスとAPI Gatewayを連携することもできます。
Amazon Cognitoは、ユーザーアイデンティティ (ユーザープールとフェデレーテッドアイデンティティの両方)を管理し、すべてのAWSサービスとSAPバックエンドにまたがってログインしているユーザーのコンテキストを保持することで、これらのサービスをセキュアに結び付けます。

設定方法

それでは、このアーキテクチャを実装してみましょう。API Gatewayを介してSAPが提供するサンプルサービスを公開します。サンプルサービスに関するSAPの文書を参照してください。このサービスは、ビジネスパートナー、連絡先、受注、および製品などの様々なビジネスオブジェクトをODataサービスとして公開します。

プライベートサブネットにSAP NetWeaver Gateway Advanced Business Application Programming (ABAP)システムをインストールします。開発者エディションは、SAPからSAP NetWeaver AS ABAP 7.51 SP02、あるいはSAP NetWeaver AS ABAP 7.51 SP02 on HANA (Cloud Appliance Library edition)で入手できます。
SAPシステムをインストールして設定したら、Amazon EC2 コンソール (https://console.thinkwithwp.com/ec2/)を開きます。ナビゲーションペインの[ロードバランシング]にある[ロードバランサー]から、[ロードバランサーの作成]を選択し、Network Load BalancerとしてSAP NetWeaver ABAPシステムをターゲットとした内部ロードバランサーを作成します。Network Load BalancerのDNS名を記録しておいてください。後でAPI Gatewayを設定するためにこの情報が必要になります。
API Gateway コンソール (https://console.thinkwithwp.com/apigateway/)からVPCリンクを作成します。これにより、API Gatewayを介してプライベートサブネット内のSAPシステムに安全に接続できます。
API Gatewayは、パススルーとしてのプロキシ統合をサポートしています。これは、API Gatewayがクライアントとサーバー (この場合はSAP)間のリクエストとレスポンスを単純に渡すようにしたい場合に便利です。/sap/opu/odata/IWBEP/GWSAMPLE_BASIC/{proxy+}のパスを持つプロキシリソースを作成します。
様々なHTTPメソッド (GET, PUT, POSTなど)を処理できるよう、リソース{proxy+}にANYというメソッドを追加し、VPCリンク経由でSAP Gatewayシステムにプロキシします。ステップ2で記録したDNS名を覚えていますか。ここで、そのDNS名をエンドポイントのURLとして使用します。
これで、API Gatewayの層でいくつかのリソースをキャッシュでき、バックエンドのSAP Gatewayシステムとラウンドトリップする必要がなくなりました。キャッシングは、APIのパフォーマンスを向上させます。この例では、SAPシステムでは頻繁に変更されないマスターデータの製品データをキャッシュします。データをキャッシュするには、API Gateway コンソールで/GWSAMPLE_BASICリソースを選択して、ProductSetという子リソースを作成し、GET メソッドを追加します。
APIをデプロイするときがやってきました。devというステージにデプロイしてみましょう！
API Gateway コンソールから、dev ステージエディターに移動し、[キャッシュ設定]にある[APIキャッシュを有効化]のチェックボックスをオンにします。[キャッシュキャパシティー]を0.5GBに設定し、[キャッシュ有効期限 (TTL)]を3,600秒に設定します。キャッシュの生成には4〜5分かかります。
ProductSetリソースだけをキャッシュします。{proxy+}リソースのキャッシュを回避するために、 GET メソッドを選択します。[このメソッドの上書き]を選択し、[メソッドキャッシュの有効化]をオフにします。他のメソッドもすべて同じように行います。
Postmanのようなツールを使ってAPIをテストしてください。 ProductSet APIへの最初の呼び出しの後に、以降の呼び出しがキャッシュから取得されることがわかります。これを検証するには、2つの方法があります：
- Amazon CloudWatch LogsでCacheHitCountおよびCacheMissCountメトリクスを確認します。
- バックエンドのSAP Gatewayシステムを停止し、APIを呼び出します。
ProductSet APIはまだ動作するはずですが、バックエンドのSAPシステムとのラウンドトリップではなく、データはキャッシュからフェッチされます。

注: このテストでは、(認証ヘッダーフィールドに)ベーシック認証を使用しました。これはテスト目的では問題ありません。ただし、本稼働シナリオでは、認証にはOAuth 2.0 フローを使用します。SAP ABAPベースのアプリケーションは、2種類のOAuth 2.0 フローをサポートしています：
- OAuth 2.0の認可コードフロー – これはユーザーが開始するフローで、ログイン資格情報を提供できる場合に最適です。例として、ユーザーがログインを行うWebアプリケーションまたはモバイルアプリケーションがあります。
- OAuth 2.0 SAML 2.0 ベアラーアサーション – これはサーバー間の通信フローであり、1つのサーバの認証済みユーザーのユーザーコンテキストを使用して、ユーザーの関与なしに別のサーバーにログインします。例えば、OpenSAML2のようなオープンソースのSAML SDKを使用して、API GatewayはAWSにログイン済みのユーザーのSAMLアサーションを発行できるLambda関数を呼び出します。SAMLアサーションを使用すると、SAPの同一ユーザーのアクセストークンを取得できます。
これらの2つのフロータイプについては多くのことが語れますが、今後のブログ記事で詳しく説明する予定です。