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

do:kalaclism

『輝かしい青春』なんてなかった人のノート

AWS Lambda + Amazon API Gateway の使い道

Development Knowledge Memo

僕個人としては、

  • AWS Lambda + Amazon API Gateway

という組合せは、現代に黄泉返った CGI みたいなモノだと認識しているのですが、 この AWS Lambda + Amazon API Gateway 、上手く使えば Web サービスの質を向上させたり、 あるいは、経費削減とかも可能になるのでないか (未検証) と思っています。

しかしながら、 AWS Lambda + Amazon API Gateway と言う組み合わせは、 ひとクセもふたクセも有る代物なので、今回はその辺りも含め、 ザックリと AWS Lambda + Amazon API Gateway の使い道について書いてみます。

※ ただし、僕の視点は、あくまで Web 開発者としてのモノです

1. この組合せで出来るコト・出来ないコト

基本的に、

  • AWS Lambda + Amazon API Gateway という組合せ

の、出来るコト出来ないコトは、それぞれのサービスの制約の集合になります。

これは例えば、

  • Amazon API Gateway は UTF-8 なレスポンスしか返せない
  • AWS Lambda は、特別なコトをしなげれば、特定の言語しか動かせない
  • AWS Lambda は、処理時間に制約が有る

という辺りなんですが、逆に言えば、これらの制約が問題と成らなければ、 基本的に何にでも利用できます。

2. Lambda + API Gateway の使い道

今の所、

  • AWS Lambda + API Gateway が向く使い道

として僕が思い付いている使い方は、

  1. Node.js (Lambda) での Server-Side Rendering Frontend としての利用
  2. ランタイムを問わず、Web hook の callback 先としての利用
  3. 簡易フォームなどの、VM の インスタンスを立てるまでもない処理

辺りです。

それで、2番と3番に関して言えば、これは CGI 代わりに使う、という感じのイメージですが、 1番についてもう少し説明と言うかアイディアの詳細を書くと、

  1. Lambda では Node.js v4 を Runtime とする
  2. API Gateway は Routing に用いる
  3. Lambda + API Gateway からの Backend の問合せには GraphQL 辺りを使う

という感じです。

そして、なぜ

  • Lambda (Node.js v4) + API Gateway を Server-Side rendering の Frontend

とするのが良いのかと言うと、理由としては、AWS にインフラを集約している場合、 Node.js での Server-Side Rendering を行うためだけに VM のインタンスを用意する必要がない 、 と言うのと、あとは、GraphQL などの、API 用の Interface を間に挟む事によって、 Backend 側の更新などが行いやすくなる、という辺りです。

まあ基本的には、

  • Frontend と Backend が疎結合となり、コスト削減にも繋がる

という辺りがメリットだ、と僕は思っています。

ただまあ、最近開発とか出来てない影響で、これについては未だに検証出来てないので、 実際のサービス運営でそれが通じるかどうか、については、未知数ですが。

まあでも、基本的には Lambda + API Gateway は、あんまりコストが掛らない、 という認識なので、まあ多少はなんとかなると思いますけども。

3. ただし、やり過ぎには注意

ただまあ、いくら Lambda + API Gateway がコストが抑えられて気楽に使えるから、 と言っても、それですべてを完結させる CGI-like な 環境として使うのは、ちょっとどうかなーって思っています。

と言うのも、特に僕にとっては、

  • AWS Lambda + Amazon API Gateway + 何かのデータストア

で完結させられるサービスを作るのは、楽だしコスト安いし、マネーを投下し続ければ無限にスケールするし、 で、良い事づくめな印象なんですが、いかんせん AWS に強く依存してしまうので、インフラを乗り換えにくくなる、 と考えられますし、また、AWS のインフラがなんらかの事情で止まってしまうと、そのサービスも無論死にます。

そのため、ミッションクリティカルと言うか、完全なサービス停止が要件上出来ないサービスに、 この組合せを用いるのは、ちょっと止めといた方が良いんじゃないかな、と僕は思います。

ただ、そうは言っても、ちょっとした Web Application で、Heroku とかでもオーバースペックな用途だと、

  • AWS Lambda + API Gateway を CGI-like に使う

と言うのは、結構良い選択肢なんじゃないかなー、と僕は思います。

と言う事で以上です

まあ、AWS Lambda + Amazon API Gateway という組合せは、簡単な Web Application を載せたり、 あるいは、フロントエンドサーバをコスト削減しつつ用意する、という用途にはかなり向くのでは? と僕は感じているので、もし案件等に合えば、使ってみるのも手じゃないかなーと思います。

Web を内容毎に自動分類する上での処理の流れ

Development Knowledge AI

概要

  • Web ページを内容毎に自動的に分類したい!

と考えた時に、

どの様にその処理を行なえば良いか

と言うのを今日調べてたので、一度考えを整理する意味でも書き出してみます。

Web を内容毎に自動分類する上での処理の流れ

基本的にはプログラミング言語を問わず、下記の様な流れになるっぽい:

  1. Web ページから本文を抽出する
  2. 抽出した本文を分かち書きをする (特に日本語の場合)
  3. 分かち書きをしたテキストを、ベクトルやスコアなどに変換する
  4. そのベクトルやスコアから、関連度を抽出する
  5. そして最後に、その関連度を利用して分類する

そして多分、どれも機械学習とかニューラルネットワークを絡ませる事は出来るんだろうけど、 まあ、その手のヤツは 3 番から絡ませた方が良いんでね? と個人的には思います。

以上

僕自身、機械学習についてまだ良く判ってないんで、あんまりこの内容も正確じゃないですが、 ま、多分こんな感じの流れになるんだろうな、と、今のところは思ってます。

なんか突っ込みとか有れば、コメント欄でよろしくお願いしますです。はい。

Ricty + Powerline + NERDFonts

Fonts Knowledge

の作り方メモ。

手順

  1. まず、Ricty を合成する
  2. 次に NERDFontfont-patcher を使って Ricty にパッチを当てる
  3. 最後に、Powerline の fontpatcher を当て直す

なぜこの手順が必要か

  • 単純に NERD Fonts を当てるだけだと、矢印フォントで隙間が開く (CJK 環境の場合)
  • で、 Powerline fontpatcher を当て直すと、それが一応は直る
  • なので、Ricty -> NERD Fonts -> Powerline の順序で作ってく必要がある

既知の問題点

  • 合成されたフォントの文字サイズが微妙にブレてる
  • そのため、使用アプリによっては文字サイズがやたらデカくなる (場合もある)
  • この辺り、フォントのサイズを調整しないとダメそうなので、自分は放置している

以上

何か有ったらコメント欄でお願いします。