ツイートできないことを Twitter でツイートしようとしたら。

ツイートできなくて詰んだ。泣きそう。

広告
カテゴリー: 未分類 | コメントをどうぞ

マージソートを実装してみた

 というわけで、今日は別名、安定ソートの名で知られている、マージソートを実装してみます。

 いや、なんで、みんな大好き爆速アルゴリズムであるところのクイックソートではなく、マージソートなのかと言えば、まぁ、速い速い言うても、所詮は、O(N2) ですし、分割統治法というアルゴリズムの原理的にどんだけ最悪なケースにしたところで O(NlogN) な点は玄人好みかと思います。先に触れている通り、安定ソートなので、同順位のものがあった場合に、その順番が、ソート前とソート後で保たれます。このあたりも、玄人好みかなぁと思います。

 で、まぁ、アルゴリズム的なものは、Wikipedia 先生に頼ればいくらでも転がっているので、ちょっと、転載してみましょう。

const merge = exports.merge = async(A, B, left, mid, right) => {
    let i = left;
    let j = mid;
    let k = 0;
    let l;
    while (i < mid && j < right) {
        if (A[i] < A[j]) {
            B[k++] = A[i++];
        } else {
            B[k++] = A[j++];
        }
    }
    if (i == mid) {
        while (j < right) {
            B[k++] = A[j++];
        }
    } else {
        while (i < mid) {
            B[k++] = A[i++];
        }
    }
    for (l = 0; l < k; l++) {
        A[left + l] = B[l];
    }
};

const merge_sort = exports.merge_sort = async(A, B, left, right) => {
    let mid;
    if (left == right || left == right - 1) { return; }
    mid = Math.floor((left + right) / 2);
    await merge_sort(A, B, left, mid);
    await merge_sort(A, B, mid, right);
    await merge(A, B, left, mid, right);
};

 なにやらおかしげなことを要所要所に書いているみたいですが、気にしません。とりあえず、これを、Wikipedia 先生の言う通り、

(async() => {
    const a = await [8,4,7,2,1,3,5,6,9,10];
    const n = 10;
    const b = new Array(n).fill(0);

    let i;
    await merge_sort(a, b, 0, n);
    for (i = 0; i < n; i++) {
        console.log(a[i]);
    }
})();

などと実行してあげれば、

1 
2 
3 
4 
5 
6 
7 
8 
9 
10 

と、きっちり、a はソートされた状態となります。ね、簡単でしょ?

 まぁ、ソースコードからも明らかなように、一般に、配列 a がある場合に、それと同じサイズ以上の作業領域、ここでは b というものが必要となるのが宿命です。インプレイスにソートできる同じく O(NlogN) なヒープソートや、意図的に病的な入力を入れると時に狂ったように遅くなるけど、まぁ、おおよそ常識的に真っ当な入力の場合、おおよそ爆速になる、みんな大好きクイックソートは、その名の通り爆速になるわけで、これらと比べて、なかなかここが好いと云えないあたりが、まさに、玄人好みと言われる所以だと思うのですが、どうでしょうか。

 というわけで、個人的にはマージソートが好きです。でも、コームソートの方がもっと好きです。

 おわり

・・・と、ここで、記事が書き終えられたのなら、どれだけ幸せだったでしょうか?

 当然、そんな Wikipedia からコピペしただけのような記事が書きたくて、長々と書いてきたわけではありません。なぜ、ソースコード上に、async だの await だのと意味深に書いてあるのか。

 というわけで、例によって例の如く、マージソートを、AWS Lambda で実装するとどうなるのか。これが、次回からのお題です。

つづく

カテゴリー: コンピュータとインターネット | タグ: , , , , | コメントをどうぞ

小ネタ:Digest 認証が許されるのは厨二病患者までだよねー – 2. もどきだっていいじゃない、人間だもの。

 というわけで、小ネタということで始めたはずの前回のラストですが、いきなり雲行きが妖しくなって行きました。

 まぁ、真っすらに実装するのであれば、こうすればいいだけの話だったはずです。

return {
  "statusCode": 401,
  "headers": {
    "WWW-Authenticated": `Digest realm="realm", nonce="${nonce}", algorithm=MD5, qop="auth", charset="UTF-8"`
  }
};

 ところがぎっちょん、こんな単純でノータリンな思想を持っているヘナチョコエンジニアの発想如き、慈悲無き AWS の中の人 が通すはずもありません。

 こんな感じに、ギッチギチに制限を掛けているというのが世知辛い現実です。

 というわけで、AWS の流儀に従う必要があります。それが、ゲートウェイレスポンスと言う奴ですね。こいつに、401 Unauthorized だったときに、どんなヘッダを返却するのかを定義してやる必要があります。

 CloudFormation テンプレートで書く場合には、AWS::ApiGateway::GatewayResponse リソースか、OpenAPI v3 で x-amazon-apigateway-gateway-responses を使って定義してやります。

        x-amazon-apigateway-gateway-responses:
          UNAUTHORIZED:
            statusCode: 401
            responseParameters:
              gatewayresponse.header.WWW-Authenticate: '''Digest realm="realm", nonce="4decd3226374c91a9b79238c27cc6937",
                  algorithm=MD5, qop="auth", charset="UTF-8"'''
            responseTemplates:
              application/json: '{"message":$context.error.messageString}'
              text/html: <html><body><h1>401 Authorization Required</h1></body></html>

 よく見てみると、nonce が定数だったりするので、これだと、Digest 認証もどきですね。どうにかして、レスポンスのなんらかのデータを割り当ててやりたいところなのですが、そんなことを AWS の中の人が許してくれるわけもありません。

 うーん、どうやって実現するんですかねぇ、実際のところ。

 まぁ、とにもかくにも、これで、ポップアップ、あ、クソダサポップアップは出せます。

 あとは、Authorization ヘッダを読んであげればいいだけですね。

 ・・・ちょっと疲れたので、ここまで。

つづく

カテゴリー: コンピュータとインターネット | タグ: , , , | コメントをどうぞ

小ネタ:Digest 認証が許されるのは厨二病患者までだよねー

 というわけで、Digest 認証が許されるのは厨二病患者までです。

 あ、もちろん、小学生でないなら、Basic 認証なんて恥ずかしいものについては、もう、触れなくていいですよね?

 さて、まぁ、Digest 認証も、十分恥ずかしいのですが、何はどうあれ、ブラウザ、あるいは、ブラウザもどきであっても、ネイティブに認証 UI を、・・・クッソだっさい UI を出すことが出来るという点や、cURL とかでも標準で対応している点など、なかなかに捨てがたいものではあります。

 で、まぁ、生パスワードをバックエンドサーバに渡さなくてもいいというだけ、べーなんちゃら認証と比べて、マシと言えばマシと言えないこともないかと。まぁ、どちらかと言えば、渡さなくていいとかいうポジティブな理由ではなく、いやいや、渡してくんなよ生パスワード、どうすんだよ、これ・・・とかいう、かなりネガティブな理由で、マシなわけですが。

 もちろん、MD5 とかいう1つ前の時代には終わっていたハッシュ関数を使っているわけで、おおよそ、安全とかそういうものとは縁遠いものです。まぁ、そんなものであろうが、とりあえず、SSL/TLS とかいうものを使っていれば、仮にベーなんちゃら認証だったとしても、とりあえず、よっぽど病的なセキュリティホールでも開けてない限り、改竄だとかそういうものに、怯える心配は、とりあえず、飛行機とかいう鉄の塊が事故って墜落するよりはしなくていいかと。

 と、まぁ、そういうものですが、仕様に少しだけ踏み込んでみましょう。

 基本的に、

A1 = ユーザ名 ":" realm ":" パスワード
A2 = HTTPのメソッド ":" コンテンツのURI
response = MD5( MD5(A1) ":" nonce ":" nc ":" cnonce ":" qop ":" MD5(A2) )

というフォーマットで、ブラウザからバックエンド側にデータを送り、

MD5(A1)

の値が一致するかどうかを確認して認証するというのが、基本的な仕組みとなります。

 あくまで、

A1

ではなく、

MD5(A1)

であるということが要訣で、MD5 がなんちゃって一方向関数であるが故に、バックエンド側は、最初から最後まで徹頭徹尾、

A1

、すなわち、生パスワードを知ることはないですし、知る必要もありません。

 べーなんちゃら認証は、このあたりが適当で、見る人が見ればそのままパスワードが何であるか分かる状態で堂々と送り付けます。一方、一応、建前としては、MD5 をかましているので、Digest 認証の場合は、そう簡単には、好きなパスワードに改竄したりとかいうことが出来ません。まぁ、実際は簡単なんでしょうけど。

 さて、最後に、例のポップアップ UI、もとい、クソダサポップアップ UI を出す方法についても書いておきます。
 これは、バックエンドサーバから、こんな感じのレスポンスヘッダを投げつけることで実現できます。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="realm", nonce="4decd3226374c91a9b79238c27cc6937", algorithm=MD5, qop="auth", charset="UTF-8"

 まぁ、要するに、こんなヘッダをくっ付けて、クライアントから、いい感じに、MD5(A1) が返却されたら、それをバックエンド側で持っている MD5(A1) と突き合わせてあげれば認証が実装できるわけです。ここまで分かってしまえばあとは単純、それを実現するように、API Gateway + Lambda で実装してあげれば、実現できるわけです。ね?簡単でしょ?

 ・・・まぁ、例によって例の如く、AWS の中の人が、そんな単純でノータリンな思想を持っているヘナチョコエンジニアの心なんてもの、へし折らずには、・・・まぁ、居られないわけですが・・・。

 あ、あれ?小ネタのつもりだったんだけど、まだ、続くの?

つづく

カテゴリー: コンピュータとインターネット | タグ: , , , | コメントをどうぞ

それでも API Gateway から画像を落としてブラウザで表示したいんだ – 6. S3 という名の希望

 さて、前回までで、完全に心を折られてしまったわけですが、それでも、API Gateway にリクエストを投げて、ブラウザで画像を表示することはできないのでしょうか?

 もちろん、初回に書いたように、結論。素直に S3ホスティングして落とせばいいじゃない。キリッ としてもいいわけなのですが、例えば、

aws s3 cp --recursive ./lambda/helloworld/images/ s3://$WEBSITE_S3_BUCKET/images/ --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers

などと、全世界に大公開して、直接コールするより他に実現できないのでしょうか?

 こうなってしまったら、考え方を変えてみるのがいいかもしれません。そうです、「API Gateway 経由でリクエストして、結果的に画像を表示できればいい」わけです。それは、何も、API Gateway から「画像を落として」あげないと実現できない話ではありません。

 とりあえず、何はともあれ、Lambda 関数のパッケージに画像やらバイナリデータを抱えてても、実際のところ、いいことは何もありません。定跡通り S3 にアップロードしておきます。ただし、

--grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers

を付ける必要はありません。

 じゃあ、どうやって表示するのか?

 S3 にはあるのです。公開されていないはずのデータを、それでも表示する方法が。

const params = { 
    Bucket, Key, Expires 
}; 
const url = await new Promise((resolve, reject) => { 
    s3.getSignedUrl("getObject", params, (err, url) => err ? reject(err) : resolve(url)); 
}); 

 そう、署名付き URL という奴ですね。Expires で指定した時間だけ有効なアクセストークンをクエリにくっ付けてくれます。そして、これを、こんな風に返却してみるとどうなるでしょうか?

return {
  "statusCode": 302,
  "headers": {
    "Location": url
  },
};

 ブラウザは、うまいことこれを解釈して、S3 から画像をうまいことリダイレクトで表示してくれるようになります。

 もう、これでいいんじゃあないかな?

 まぁ、やってみれば分かるのですが、単純に公開されている S3 に直でアクセスするよりも倍以上の時間が掛かります。

 というわけで、結論。素直に S3ホスティングして落とせばいいじゃない。

おわり

カテゴリー: コンピュータとインターネット | タグ: , , , | コメントをどうぞ

それでも API Gateway から画像を落としてブラウザで表示したいんだ – 5. Integration Response とかいう忘れ去られた負の遺産

 というわけで、前回、あれだけ大口叩いて 絶対に不可能です キリッ とか言ってたのは、ウソばっかりでした、というお話をしたのですが、ネタ潰しよくないです。俺達の旅はまだ始まったばかりだ!!

 元々、何の話をしようとして、これまで前振りをしてきたかというと、「Lambda プロキシ統合」とかいう得体の知れない奴は、本当に得体が知れないのか? というのが最初のテーマでした。これについても結局、得体の知れない奴です、という結論になってしまうのですが、まぁ、せっかく記事書いたんで。

 既に、Lambda プロキシ統合とかいう幻想とかいう記事を書いているので、実際、ここまで話を戻すのですが、では、

- type: "aws_proxy"
+ type: "aws"

として、Lambda プロキシ統合と等価なものを実現できるでしょうか?

 まず、こんなことを考えている動機は、既に書いていますが、

IntegrationResponse リソースの contentHandling プロパティを CONVERT_TO_BINARY に設定して、レスポンスペイロードが Base64 でエンコードされた文字列からそのバイナリ BLOB に変換されるようにする

という話が復活させられるからですね。

 まぁ、復活しないんですけど。

 ところが、これも既に書いたように、aws-serverless-express に限らず、ほぼすべての世の中にある API Gateway + Lambda バックエンドについては、Lambda プロキシ統合であることを前提としていると断定しても良いわけで、この令和の時代にあって、

"type": "aws_proxy"

を使わないのは、もはや趣味とか言うレベルに留まらず、正直、奇行と言わざるを得ないのではなかろうかと思います。

 まぁ、だからこそ、こういう風に記事にできるんですけど。

 そもそも、Lambda プロキシ統合とはどういうものなのか。もう一度、きっちり再復習してみましょう。

[1] リクエスト
 最初の特徴ですが、渡されたリクエストを application/json で渡してくれます。何を当然のことをと言いたくはなるのですが、こと AWS のことを語るのに当たり前とかそういう考え方はさっさと捨て去って諦めることを強く推奨します。とにもかくにも、

クライアントが API リクエストを送信すると、API Gateway は、統合された Lambda 関数に raw リクエストをそのまま渡します。-中略-。このリクエストデータには、リクエストヘッダー、クエリ文字列パラメータ、URL パス変数、ペイロード、-中略- 現在のデプロイステージ名、ステージ変数、ユーザー ID、または承認コンテキスト (存在する場合) を含めることができます。

です。これらを、このフォーマットに従って整形してくれます。

 もはや当たり前に思えるこれも、実は、本来、統合リクエストで、マッピングテンプレートとかいう、奇妙奇天烈な書式でフォーマットの変換を施す必要があります。まぁ、これが、難解極まりない、おおよそ、常人の理解の外側にある代物ではあるのですが、まだ、とりあえず、ドキュメントを精神をすり減らしながら読んでいけば、それっぽそうなものは出来なくはなさそうな気がしなくもありません。

 ですが、正直、本当の闇は、リクエストではありません。タイトルの通り、レスポンスにあります。

[2] レスポンス
 レスポンスについても、このフォーマットに則って記述してあげると、いい感じに、返却してくれる、と言ってくれているのですが、これが、まぁ、ほとんどルール違反に近い凶悪なブラックボックスとなっています。

 まぁ、まだ、”body” の方は理解するには苦しいですが、何はともあれ、どんなものであろうが、UTF-8 で返却できればよいというものです。これをこれまたマッピングテンプレートとかいう摩訶不思議な代物を使って、どうのこうのすれば、どうにかなると言っているのですが、まぁ、そう言っているのは、恐らく、この広い世の中見回しても、AWS の中の、きっと途方もなく優秀なエキスパートな人だけではなかろうかと思います。まぁ、まだ、それでも、ここまでは可愛げがある方で、本当の本当の深淵は、body ではなく、headers にあります。

 そもそも、しつこいレベルで繰り返しになりますが、Content-Type と Accept を一致させる必要があります。従って、当然のように、

Content-Type: image/png

を返却しなくてはならないわけで、これは Lambda プロキシ統合の場合、

{
  "headers": {
    "Content-Type": "image/png"
  }
}

などといった形に返却すると、凶悪なブラックボックスの中で禁術が行使された結果、なんやかんやあって、どうにかなるのですが、当然、そのすべてを詳らかに記述する必要性に迫られます。

 ・・・が、実は、ボディ以上に、レスポンスヘッダを返却、もとい、解釈ひとつするだけのために、強烈かつ凶悪な縛りが要求されます。

 もはや、ドキュメントを読んで、まともに理解すること自体が困難なのですが、今のところの理解としては、恐らく、Method Response でステータスコードごとにヘッダを指定し、Integration Response で指定されたステータスコードごとにヘッダを Lambda のレスポンスから取得してこれを書きかえる・・・のか? と読み取れます。まぁ、その通りにマネージメントコンソールで手作業でやってみようなんて思ってしまったら最後、精神を抉られますので絶対にやめましょう。
 AWS のマネージメントコンソールと言えば、肝心要の機能に限って、致命的なバグの温床で有名なのですが、特に、API Gateway については、UI/UX を含めてオブラートに包んでも劣悪極まりないと言わざるを得ません。もはや、自分が間違った操作をしているのか、UI が狂っているのか、仕様がバグっているのか、はっきりしたことが言える存在があるとすれば、もはや、人の領域から外れた存在なのではなかろうかと思います。

 とはいえ、そこまで努力して、とりあえず、それでも、SAN 値削られながら、やってみたんですよ。

 一応、記事に書くんだから、その徒労、もとい、努力の結果くらいは残そうかなぁと思って。

 ・・・ここまで、全部やっても、API Gateway は、絶対に、意地でも、バイナリファイルを返してくれません。全力で UTF-8 でグシャグシャに汚してポイ捨てしてきます。っていうか、そのまま返せよ、本当に。なんでいらないことをしたがり屋さんなのかな?!

 デプロイしてブラウザで表示されないことを確認する度に、心が擦り減るのを感じながら、あーでもこーでもないとやっていると、心を病んでしまいます。絶対にやめましょう。

 まぁ、そんなことしなくても、もはや、こんな負の遺産を、精神を病んでまで抱え続ける必要性なんて一切ありません。大人しく、最初から、Lambda プロキシ統合しかこの世にはなかったのだと諦めましょう。

 なんか、長くなってしまいましたが、次回、現実的な解を追求してみましょう。それでも、精神をガリガリ削ることなく、API Gateway でブラウザでも表示できる画像を表示するには、どうすればよいのか。

つづく

カテゴリー: コンピュータとインターネット | タグ: , , | コメントをどうぞ

それでも API Gateway から画像を落としてブラウザで表示したいんだ – 4. CloudFront Lambda@Edge とかいう黒魔術

 前回までで、

<img src = "/images/image.png" />

を表示するという問題が、

- Accept: image/webp,image/apng,image/*,*/*;q=0.8
+ Accept: image/png

にリクエストヘッダを置き換えるにはどうすればよいかという問題に置き換わりました。

 現実的に、これを API Gateway だけで実現するのは、まぁ、不可能なのですが、そのためには、API Gateway の親玉、CloudFront について知っておく必要があるかと思います。

 実際、API Gateway 自体が、CDN であるところの CloudFront の劣化版、もとい、AWS の中の人基準で良い塩梅だと思い込んで作り上げた得体の知れないブラックボックスなのですが、そのくせ、CloudFront 自体ではないと AWS の中の人が必死に言い張っているせいで、ごくごく当たり前のことを実現しようというだけで、CloudFront とかいう重戦車を二重に背負わせないと何もできないわけですね。

 実際、CloudFront を合わせて二重掛けしてあげることで、まぁ、これでも不満かと言わんばかりに、多岐に渡るとてつもない数の設定項目を指定できるわけですが、それに輪を掛けて拡張性を付けさせてやろう、どうだ嬉しかろう?と AWS の中の人が付けてくれたのが、この、Lambda@Edge というものです。

 これを使えば、CDN であるところの CloudFront を中心として、CloudFront へのリクエスト、CloudFront からのバックエンドへのリクエスト、バックエンドから CloudFront へのレスポンス、そして、CloudFront からのレスポンスという4つのタイミングで、Lambda 関数を実行して、ヘッダやらボディやらを参照したり書き換えたりすることができるというものです。

 まぁ、要するに、今まさに求めているものそのものですね。

 長々と書いても仕方がないので、結論だけを書きます。

lambda/edge/index.js

exports.handler = async (event, context) => {
    const {request} = event.Records[0].cf;
    const {headers} = request;
    headers["accept"] = [{
      "key": "Accept",
      "value": "image/png"
    }];
    return request;
};

まぁ、こんな感じで request が飛んできますので、中身を書き換えて、request を return してあげればいいわけです。ね?簡単でしょ?

 まぁ、AWS の中の人がそんな安直なやり方を許してくれるほど優しい存在であったのなら、半分が優しさで出来ているバファリンなんてものはこの世に必要ありません。
 
 本当に、本当に、頭を抱えてバファリンをダース単位で摂取したくなるような、どうしようもない制約条件が掃いて捨てるほどあります。

・CDN 二段掛け
 そもそも、こっちは、当たり前のようにただ単に画像が表示したいだけです。何を思って、CDN を二段掛けしなくちゃあならんのでしょうか。本番サービスでグローバル展開したいとか、何が何でも高速に捌きたいとか、もちろん、その利点を最大限に享受したいのならごく当然に利用すればいいのですが、たったそれだけのために使う必要があるのかどうか。

・書き換える条件
 そもそもの条件ですが、Content-Type と Accept を一致させる必要があります。簡単に言ってくれちゃってますが、世の中、バイナリファイルの MIME タイプなんて、それこそ、掃いて捨てるほどあるわけです。

 PNG が表示できるのなら、JPEG だって、かの悪名高き GIF だって表示したくなりますし、なんだったら、音声だって、動画だって、何でもかんでも表示したくなるのが世の常というものです。

 その全てに、例外なく、上記の書き換えが必要となるわけですね。

 そもそも、Content-Type 自体が何になるのかを決定するのだって、まぁ、拡張子を丁寧に見て、それが png かどうかを判定して、それなら、Content-Type を image/png にして・・・だとかをしようとすれば、

lambda/edge/index.js

-    headers["accept"] = [{
-      "key": "Accept",
-      "value": "image/png"
-    }];
+    if(headers["accept"]) {
+        const accept = headers.accept;
+        for(const head of accept) {
+            if((head.value || "").search("image") !== -1 && request.uri) {
+                if(request.uri.search(/\.png$/) !== -1) {
+                    head.value = "image/png";
+                } else if(request.uri.search(/\.jpg$/) !== -1) {
+                    head.value = "image/jpg";
+                } else if(request.uri.search(/\.gif$/) !== -1) {
+                    head.value = "image/gif";
+                }
+            }
+        }
+    }

というような、あたまのおかしいコードを書かなくてはならないわけです。
 当然と言えば当然ですが、template.yml も書き換えますし、aws-serverless-express に渡すパラメータもバカ正直に書き換える必要があります。

・Lambda 関数の制約
 いやいや、mime でもなんでもライブラリ使えよと思うじゃあないですか。
 普通の Lambda 関数と比較してとてつもなく条件が厳しく設定されています。まぁ、レイテンシを長くしていいことなんて何もないわけですから、ある意味厳しくて当然なのですけど。

 関数に割り当てられるサイズは、圧縮して 1MB まで。実行時間は5秒を超えてはなりません。

 そして何よりまず味な制約ですが、デプロイ可能なリージョンがバージニア北部に限定されます。もちろん、バージニア北部原住民なら問題はないのでしょうけど。

・バージョン
 まぁ、リージョンについては、ACMとかにも言える話ですし、AWS なんてもの使うのなら今更な話なので、とりあえず、涙を飲んで受け入れるとして、一番最低な仕様がこれですね。

 CloudFront にデプロイできる Lambda 関数は、バージョン付けされているものを、バージョン指定付きの ARN で一意に決定しなくてはなりません。$LATEST がダメなのは当然として、エイリアスすら認められていません。

 流石に、AWS の中の人も悪魔ではないのか、これをするためだけの UI が Lambda のマネージメントコンソールに追加されたりとかされていて、全世界の手デプロイ民を歓喜させたりもしているのですが、例えば CloudFormation 使って Lambda 関数の管理を含めてやろうとするには、あんまりな仕様かと思います。ただでさえ、CloudFront なんて、CloudFormation 使ってデプロイすると、コーヒーブレイクするにも、ヤニ休憩するにも、ちょっと同僚やら上司やらから一斉に袋叩きに合いそうなレベルの時間が掛かるというのに、ちょっと、バイナリファイルの種類を変えるだけで、なぜ、そんな肩身の狭い思いをしなければならないのでしょうか?

 というわけで、方法はあるので、可能か不可能かと言えば、バージニア原住民で、かつ、同僚・上司からの冷たい視線を悦んで受け止め切れる場合には、ギリ可と言えなくもないわけですね。流石に、絶対に不可能は言い過ぎだったかと思います。

 まぁ、CDN 自体は、決して悪い機能などではありません。それはそれで非常にディープでシビアな世界のお話なので、機会があるのなら、もっと追究してもいい世界ではないかと思います。

 というわけで、この方向性について追及するのは、またの機会として、・・・本当に、他に手段はないのでしょうか?

 ・・・まぁ、結論から言えばないのですが、せっかくなので、もう少し API Gateway の可能性を追求して貴重な時間を湯水に溶かしてみましょう。人生、一度くらいそんな贅沢かつ無為に時間を溶かすのも、・・・悪いことしかないんですけどね。

つづく

カテゴリー: コンピュータとインターネット | タグ: , , , | コメントをどうぞ