2018年5月24日木曜日

【AWS Lambda】関数作成3

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

現在はAWS Lambdaの使い方を紹介中です。

前回からまだまだ続いてLambda関数のコンソール画面を調査中です。

関数コード



関数コードは、Lamda関数を実行した時に叩くロジックの管理です。

リッチエディター形式になっていますが、こんな所で実装する人いるのかしら?
普通はローカルで開発してアップロードでしょ。。。

基本は手元で開発したソースをzipファイル等の形式に圧縮してアップロードすることで展開することになります。
アップロードはコツがいるみたいなので、後日検証。

「ハンドラ」という項目がありますが、これは「実行した時に最初にどのメソッドを叩くの?」ということを設定する所です。
これについても後日検証。

環境変数



環境変数は、その名の通り環境変数。
実行環境に応じてパラメータを変えたい時に使用すると便利なものです。

代表的なものとして、秘密情報でしょうか。

例えば「本番環境用のDB接続用パスワード」をGitHubにブチ混んでいてはマズいわけですよ。

そういう時はパスワードは環境変数から取得することで、ローカルではローカルの設定でDB接続し、本番では本番環境変数でDB接続出来ます。
コミットファイル中にはパスワードが存在しないので安心ということです。

項目「暗号化の設定」は、それを更に推し進めたもののようです。

「Lambdaの画面開いたらパスワード丸見えなんだけど?」というのを避けるため、Lambdaコンソールから見える文字列も暗号化しておいてくれるという物です。

そしてソース中で復元する時は、ちゃんと元の文字列になっています。

当然ですが、パスワードをログ出力していたらブチ怖しなのでご注意を。

タグ

タグは、Lambda関数の目印です。
「メールのフォルダ分け」と似たようなもので、Lambda関数が増えてくると探すのが大変になるから、タグをつけて整理出来るようにしておくというものです。

実行ロール

ロールとは権限を管理する機能です。

つまり「この関数はS3にアクセスして良い」というような実行権限を付与するための項目です。
正しく設定しなければもちろん動きません。

関数が増えてくると、こういう所もキチンと整備し、必要最小限の権限のみを付与することで、システムの保守性が上がるわけです。

基本設定


「基本設定」は寄せ集め項目なので、適当なネーミングにしたのでしょうね。。。

説明

関数についてコメントを書いておくもの。

メモリ

重要項目。

Lambdaではメモリを関数に任意でセットします。
ここで設定しているメモリを2倍にしたら、コストも2倍というシビアな項目です。

従って、Lambda関数はメモリ節約こそが大正義ということを意味します。

最近はサーバの性能が上がってメモリも十分に搭載されており、メモリの使用量なんか全く気にしなくてOKという開発が増えてきました。
しかしLambdaでそれは通用しません。

コスト削減のため、「メモリ節約」「処理速度向上」は極限まで追求しなければならないのです。

最小は128MB、最大は3GB。

タイムアウト

関数が開始から終了までに許容する時間です。
現状だと5分が上限です。

Lambdaは小さい処理を大量実行するモデルなので、一回の実行に何時間もかかるようなバッチは思想と合っていないので使用できません。

そういう時はLambdaを使わないという選択肢もありますが、私はデータの範囲を分けて関数を複数起動するなど、あくまで小さなバッチの集積体という思想に従った方が保守性の高いシステムになると思います。

なお、この画面で設定する値の値は5分ですが、ここで設定する値はLambdaのタイムアウト時間で、HTTPリクエストに対応するAPI Gatewayトリガーの最大時間は90秒だったりします。

なので、

「あれ??? タイムアウト時間を5分に設定しているのに、90秒でエラーになっちまうぞ!?」

ということが起きるんですよ。

これは罠です。

続く

関数のパラメータ解説はもう少し続きます。

2018年5月18日金曜日

【AWS Lambda】関数作成2

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

現在はAWS Lambdaの使い方を紹介中です。

コンソール画面

前回からの続きでコンソール画面を見ていきたいと思います。

画面の上の方から行きます。



一番上に「アクション」とかボタンが並んでいますが、この辺りは作った関数をキックしたりする部分です。
これについては後続の記事で書きますので、次に進みます。

デザイナー

デザイナーは、Lambda関数を頂点に、それ以外のAWSサービスを紐づけるための機能です。

初期状態では以下二つがぶら下がっています。

  • Amazon CloudWatch Logs
  • Amazon DynamoDB


Amazon CloudWatch Logs

Amazon CloudWatch Logsは、Lambdaのログを出力するサービスです。

通常のシステムの場合、ログはログファイルに吐き出してローテーションするものですが、Lambdaのようなサーバレスのサービスの場合、無意識に使えるディスクスペースは基本ありません。
なので「ディスクスペースに吐き出す」みたいな簡単な処理に工夫が必要になってきます。

ディスクスペースの代わりにログを吐き出す先、それがAmazon CloudWatch Logsです。

イメージとしては、恐らくNoSQL型のDBにログを保存しているのだろうと思います。
そしてCloudWatchの画面でそれを参照する、というカラクリです。

CloudWatchの画面イメージはこちら。


CloudWatchにログを出力するための実装方法は後日の記事にします。

Amazon DynamoDB

Amazon DynamoDBは、アマゾン自慢のNoSQLです。

【AWS Lambda】帳票出力API開発 その2~RDBMSを使うな~

で書きましたとおり、Lambdaと通常のRDBMSの組み合わせは基本、無いです。
代わりにNoSQLを使用します。

Lambda最大の制約はココ、NoSQLを使うしか無いう点でしょう。

でも性能的には最強なんです。
最近、私はずっと「既存システムをNoSQLに置き換えることは出来ないか?」ということばかり考えています。

例えば、掲示板とかならイケるんですよ。

5ちゃんねる(旧2ちゃんねる)という掲示板がありますけど、あれってサーバ側にはテキストファイルが置いてあるだけでDBは使ってませんからね。

テキスト出力だけでやっている処理はNoSQLに置き換え可能です。

また、PukiWikiという有名なWikiツールがありますけど、あれもテキスト出力だけで実現しています。

LamdaとDynamoDBで実現するNoSQL・サーバレス型のWiki&掲示板というのは負荷の激烈増減というサービスの性質を考えると相性最強のはず。

何とかして自分で開発出来ないかと考えています。


トリガー

さて、最初からぶら下がっている二つは上記のとおりとして、気になるのは左側の「トリガー」です。

これは「何をキッカケとして、Lambda関数をキックするか?」ということを決定するための機能です。

例えば、


  • API Gateway:HTTPリクエストをトリガーとしてのキック


などですね。

以下のラインナップはあります。


  • API Gateway
  • AWS IoT
  • Alexa Skills Kit
  • Alexa Smart Home
  • CloudWatch Events
  • CloudWatch Logs
  • CodeCommit
  • Cognito Sync Trigger
  • DynamoDB
  • Kinesis
  • S3
  • SNS


すいません。
私が作ったシステムだと「API Gateway」か検証していなくて他は未検証なのですが、断片的に調査した情報だと以下の機能だと理解しています。

AWS IoT

AWS IoTというサービスと連動するもの。
例えば「目覚まし時計を叩いたら起動」とか、そういう用途が可能と思われます。

Alexa Skills Kit・Alexa Smart Home

噂のAI製品「Alexa」と連動するもの。

例えば「Alexa! 会議室は空いているか!?」とか話しかけると起動し、Lamdaの処理を経由して会議室予約システムとかと照合し、最終的には「C会議室が開いています」みたいな返事をするとか、
そういう用途が可能になると予想。

CloudWatch Events・CloudWatch Logs

ログ回り。
例えば「ログの中にFATAL」という文字が出現したらキックし、社員に緊急出勤させるような処理のためのもの。

CodeCommit

AWS CodeCommitというGitHubみたいなサービスがあるそうです。
プッシュ通知とか出せるのでしょう。

Cognito

Cognitoはシングルサインオンを管轄する機能です。
「ユーザがログインしたら起動」とか出来るものと予想。

DynamoDB

DynamoDBは上記のとおりのNoSQL。
テーブルの更新を察知することが出来ます。

RDBMSにも「トリガー」という機能がありますが、あれと似たような機能のようです。

Kinesis

Amazon Kinesis Data Streamsというストリーミング処理と連携。

例えば「動画の15分の所でCMを挟む」とかの用途と予想。

S3

S3はAWSの最初期からある伝統のディスクストレージ。

「特定フォルダにファイルがアップロードされたらキック」

SNS

SNS? FeceBookみたいな? と思ったら違いました

Amazon Simple Notification Serviceという、プッシュ通知を行ってくれるサービスがあるそうで。
プッシュ通知の中身をLambdaを使って構築しているのかな?



以上のとおり、沢山あります。

これらから分かるとおり、LambdaはAWS製品を使う上での基幹部分に位置する超重要サービスだと言えます。

AWSに関わっていくなら、Lambdaへの理解は必要不可欠と言って良いでしょう。


続く

引き続きLambdaの関数設定について調査していきます。

2018年5月11日金曜日

【AWS Lambda】関数作成1

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

今回はAWS Lambdaで関数を作成するところまで行ってみましょう。

ログイン

ログインするためにはもちろんID登録をする必要があり、ID登録だけにも権限とか注意点があるのですが、そこは割愛。

ログインした所からスタートします。

以下が私のLambdaのコンソール画面です。

https://ap-northeast-1.console.aws.amazon.com/lambda/home?region=ap-northeast-1#/functions


既に関数を作って稼働させているのでメニューに一つ関数があります。

ブログのストーリー進行の都合上、もう一個関数を作りたいと思います。

関数作成

右上にあるオレンジ色のボタン「関数の作成」をクリックします。

すると以下の画面に遷移します。



メニューが三つあります。

一から作成

説明文にあるように「Hello World」を出力するという、最小空っぽ構成でスタートするというものです。
一から全部自分で構築します。

設計図

メニューから選択し、最初からある程度構成された状態でスタートするものです。

初心者の自分としては「ゼロから構築するのは難しいし、最初からそこそこ動くなら便利そうだな」と思って私はこれを選択しました。

が、ハッキリ言って動かねえ!!

これね、確かに最初から多少なりともセットアップされた状態でスタート出来るのですけど、恐らくセキュリティとかの都合だと思うんですけど、とにかく疎通しない状態からスタートしやがるんですよ。

いや、とりあえず「テスト」とかやれば動くんですけど、「HTTPリクエストの受付」とか肝心なところになると全然ダメ。

初心者の自分には動かない原因なんて分からないですからね。
結局、一個一個理解してようやく動かすに至りました。

まあ、どんなもんかと思ってとりあえず設計図を選ぶと分かることもありますが、結局は一から作成するのと同じくらい理解に時間を費やす覚悟が必要です。

サーバレスアプリケーションのリポジトリ

これは私も未調査ですが、どうやら世界中のエンジニアが「私もAWSの関数を作ってみました。ぜひ使ってください」というのを公開しているようですね。


Yuji Nishimura.
西村 祐司さん? 日本人の方もいらっしゃるようです。

コメントを見る限り「挙動確認の為に試しに公開してみた」という物に見えます。結構フリーに公開出来る環境なようです。

探せば何か面白い関数が眠っているかもしれませんね。


さて、今回は「一から作成」で進んでいきたいと思います。

ランタイム

関数名は適当に「TacyBlogSample」として、次にランタイム。
実行言語を選択します。


2018年現在だと以下のラインナップです。

  • C# (.NET Core 1.0)
  • C# (.NET Core 2.0)
  • Go 1.x
  • Java 8
  • Node.js 4.3
  • Node.js 6.10
  • Node.js 8.10
  • Python 2.7
  • Python 3.6

え? 「PHPとかRubyとか無いんだけど? 俺こんな言語知らないよ?」って?
あなた、時代に乗り遅れてますよ!!

と言うのも、Lambdaのようなサーバレス環境は言語が固定されており、メニューの中に入っている言語しか使用出来ません。

どの言語をサポートするかはクラウド業者が決めますから、クラウド業者から見て評価の高い言語しか使用出来ないということです。

つまり、AWS様は「PHPとRubyなんでどうてもええわ」と思っているってことなわけですよ。見放されています。

今後クラウドを使っていきたい人はクラウド界で人気のある言語を習得するというスキルセット戦略を持つ必要があります。

私のオススメは断然「Python」です。
いくつかクラウドサービスを見てみましたが、Pythonは必ず優先的にサポートされています。

皆さんもぜひPythonを習得して下さい。

と言うわけで、とりあえずPython3.6を選択。

ロール

ロールというのは、権限設定です。

「この関数はファイルサーバに書き込みが出来る」
「この関数はログ出力が出来る」

とかそういうのです。

私は一人で小規模なアプリを開発しただけなので余り権限を意識していませんが、複数人で大規模なアプリを開発するとなると、権限を適切に割り振る設計も重要になってくるのでしょう。

余り気にしていないと言っても、

  • 「あれ? 動かないぞ?」 ⇒ 権限が無かった。

というのは都度都度発生しますので、重要です。

ともかく、今は適当に新規で作って先に進みます。



出来上がりました。

続く

今日のところはここまで。

次回から関数コンソールの中身を見ていきましょう。

2018年4月20日金曜日

【AWS Lambda】課金体系解説【無料枠】

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。

今回はAWS Lambdaの料金解説です。

手始め

クラウド環境を使う人が真っ先に気にするのは、やはり料金ではないでしょうか?

クラウド環境が活用される理由の第一はやっぱりコストで、コストパフォーマンス良くランニングしたい人の為のサービスですから。

しかしながら、クラウド環境のコストは千差万別。
普通のレンタルサーバの場合は月々いくらの定額制が多いですが、クラウド環境は従量課金制であることが多く、「従量課金ってのは、具体的にどういう計算になるの?」という所が非常に難しいです。

特にAWSは数あるクラウド環境の中でも課金体系が複雑な方だと言われており、これはAWSの欠点の一つだと言えるでしょう。

ともかく今回はLambda部分の課金についてご説明です。

GB-秒課金

こちらがLambdaの料金の公式ページです。


そこにはこう書かれています。

Lambda では 1 か月に 1,000,000 件の無料リクエストおよび 400,000 GB-秒のコンピューティング時間が無料利用枠となっています。

400,000 GB-秒のコンピューティング時間って何ぞや???

普段は余り耳にしない独特の単語が出てきました。

  • GB-秒
  • コンピューティング時間

これを分かり易い言葉に置き換えると、こういうことなんです。

  • インスタンスのメモリ×実行時間

つまり「AWS内のメモリを累計でどれだけ消費したか?」で課金されるという意味になります。
以下の青色の面積が課金対象です。


インスタンスのメモリ

「インスタンスのメモリって何のこっちゃ?」という方もいらっしゃるかもしれないので、Lambdaの画面の一部を切り抜いてお見せしましょう。

以下のように、Lambdaコンソールの「基本設定」蘭にメモリを指定する項目があります。これがインスタンスの設定メモリです。




一番小さい設定で128MB、一番大きい設定で3008MBになります。
(何故3008MBなどという中途半端な値なのかは不明)

課金基準は「インスタンスのメモリ×実行時間」なので、このメモリのサイズに正比例して料金が上がっていくことになりますね。

ここでお分かりになると思いますが、Lambdaはメモリが小さいほど正義なインフラという意味になります。

通常のサーバの場合、「メモリが8GBなら8GBをフルに使わないと勿体ない」という発想で、積んであるメモリをキッチリ使い切ることが芸術です。

そこがLambdaは全然違って、メモリの正比例でお金がかかっていきますから、可能か限りメモリを少なく済ませることが財布に直結するという、プログラマーの腕の見せ所なインフラなのです。

従って、採用する言語もメモリを余り使わない言語の方が優れているということになり、メモリを大量消費する言語であるJavaはLambdaとの相性が最悪です。

私のエンジニアとしての経歴はJavaを起点にしていますが、来るべきクラウド時代を考えるとJavaのみしか使えないエンジニアは活躍の場所が限られると考えています。

「Javaエンジニアは、主力言語はJavaのままでも良いが、補助としてもう一つ言語を覚えるべき」

という私の持論はここに起因しているわけです。

インスタンスの実行時間

インスタンスの実行時間はそのまま、処理が開始されてから終了されるまでの時間です。

  • 1秒で処理が完了したら、1秒を課金。
  • 3秒で処理が完了したら、3秒を課金。

プログラムの速さが料金に直結してくるという、やはりプログラマーの腕の見せ所なインフラなのです。

課金は秒単位で行われます。
どういう意味かと言いますと、昔は

  • 課金は時間課金。
  • インスタンスを30分使っても課金は1時間。
  • 1秒使っても1時間分の金を払いやがれ!!

というカツアゲみたいな課金体系でしたが、クラウド黎明期はこれでも凄いことだと言われていたそうです。
今は1秒単位なので、随分効率が良くなりましたね。

しかし、プログラマーとしては結構キツいなぁ。

「この処理、今は3秒かかっているけど、工夫すれば2秒になるんじゃない?」

とか言われちゃうってことでしょ?
キッツ~。

あと、当たり前ですが、アクセスが殺到してインスタンスが複数立ち上がったら、その正比例でコンピューティング時間に追加されていきます。

無料範囲

こう考えると「400,000 GB-秒のコンピューティング時間が無料利用枠」という意味も分かってきますね。

メモリが128MBの場合、

  • 400,000(GB・秒) ÷ 128(MB) = 3,125,000(秒) = 868時間 = 36 日

という計算になりますね。
だから、立ち上がるインスタンスが1コならずっとタダで使えるってことになります。

しかし、処理の都合でメモリは最低でも1280MBは欲しいとなってくると、この場合だと3.6日ということになります。

短いような気もしますが、ここで忘れてはいけないのは、あくまで「処理時間」ということです。
アクセスが来ていない時間帯は処理していませんので料金は発生しません。
Lambdaは、

  • アクセスが来ていない時は寝ている。
  • アクセスが来たら起きて処理して終わったらまた寝る。

という挙動ですからね。

サービスとしては24時間立ち上がっていても、サーバとして処理している時間が短いシステムであれば、3.6日というのはまあまあの無料枠を貰えていると考えて良いのではないでしょうか?

なかなかお得なインフラです。

手始め

引き続きLambdaの連載を継続します。

2018年4月11日水曜日

【AWS Lambda】帳票出力API開発 その2~RDBMSを使うな~

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

最近、AWSをフル活用して社内システムを作ったので、そのノウハウのご紹介を行っています。


前回に引き続き、AWS Lambdaのご紹介です。

特徴3:RDBMSを使うな

特徴3は重大です。

  • RDBMSを使ってはならぬ。

とだけ言うと語弊があるので、ここは詳しく説明していきましょう。

RDBMSとは

RDBMSが何かということは、各自でwikipediaでも見て貰えば十分かと。
リレーショナルデータベースマネジメントシステム、つまり普通のDBです。

  • Oracle
  • MySQL
  • PostgreSQL

これを使うな、とは過激な話です。

「DBを使えないシステムなんて実質役に立たないだろ!!」

と思う人も多いはず。
これには理由があるんです。

それは「コネクション」です。

コネクションの概念

通常のWebシステムの場合、まずWebシステムのインスタンスが起動し、そこからRDBMSに対してコネクションを張ります。

この時、「SQLを発行する都度、コネクションを張る」という挙動をするシステムは基本無いです。
(大昔のへっぽこシステムなら分かりませんが)

  • Webシステム起動時に一定数のコネクションを確保し、それを使い回す。

これが基本……と言うか、これ以外選択肢は無いと思います。

コネクションをいくつ取るかはアプリ側に任されていて、RDBMSは上限数までは要求されるだけ張るようになっています。



上の図はコネクション数5をイメージしています。

これはつまり、同時にSQLを実行できるのは5つまで。
6つ以上のSQLが発生した場合、5つに収まらない分は待ちになります。

よくある障害発生のパターンとして、SQLがコネクションを使ってそのまま開放しないというものがあります。
これをやられるとシステム全体のSQLが止まってしまうので、インスタンスの緊急再起動をさせることでコネクションを切って張りなおすことで回復させるのが常套手段です。
(DBまで再起動する羽目になったら目も当てられませんが)

上の図はインスタンスが一台のイメージでした。
では、ロードバランサーとかを使って、APサーバが2台ある構成のイメージを見てみましょう。


はい。
説明するまでも無いと思いますが、コネクションが2倍に増えました。

  • インスタンス毎にコネクションを確保する。

それがシステムの基本です。
ここにLambdaの罠があります。

Lambdaの特徴

Lambdaは以下が特徴のサービスです。

  • 処理が無い時はインスタンスが寝る。
  • 処理が増えた時はインスタンスが増える。
  • 処理が激増した時はインスタンスがガンガン増える。

そろそろお分かりになってきたでしょうか。

Lambdaはインスタンスの動的増減に価値を持っているサービスです。

しかし、インスタンス毎にコネクションを張るという物理的な制約は変わらない。
つまり、コネクション数が無限に増えるという仕様なのです。


この有様です。
イナゴとしか言いようがありません。

  • LambdaとRDBMSは相性が悪い。

これは覚えておかなければなりません。必須知識です。

使って良い場合

でも、カラクリが分かれば使えるシチュエーションもあることも分かるでしょう。

「インスタンスが無限に増えた時にRDBMSがボトルネックになる」が問題の核心部分ですから、インスタンスの数が制御されていれば問題にはなりません。

  • Webリクエストをトリガーとしてインスタンスを起動する場合はインスタンスがどれだけ増えるか分からないから絶対に使ってはいけない。
  • 定期バッチのように、インスタンス数がコントロールされている場合は使える。

これは大変重要な部分です。
覚えておいてください。

本システムの場合

本システムでは、Lambdaは帳票出力APIとして使用しています。
帳票出力に必要な情報は外部から全部JSONで貰うという仕様にしました。
DBにはアクセスしていません。

これが解決策なのです。


  • 必要な全データをリクエストから取得し、そのままDBを使用すること無く処理が完了する機能には最強!!


帳票出力APIにLambdaをチョイスしたのは我ながら名案です。

オマケ:それでもDBを使いたい

そんな制約がありながらも、それでもLambdaの拡張性や効率は魅力的です。

  • アクセスが少ないシステムの場合は、インスタンスが寝ているからタダで使える。
  • アクセスが増えても自動拡張してくれる。

この安定性とコストパフォーマンスは捨て難いです。
そんな人はNoSQLに活路を見出してみましょう。


AmazonのNoSQLであるDynamoDBは、GoogleのBigTableと並んで世界一有名なNoSQLです。

っていうか、LambdaもDynamoDBもGoogleのパクリとしか思え……ゲホゲホ

DynamoDBはクラウド型DBを名乗るだけあって、Lambdaのインスタンス激増から来るアクセス急増にも耐えられるように設計されています。

耐久性の秘密は分散にあります。
だから「保存したデータが別の場所からは見えない(伝搬してないから)」という現象が起きたりとか、RDBMSとはまるで別物。

分散を実現する為に「リレーション」というものが無く、従ってテーブル間結合も出来ないとか、DBをRDBMSからDynamoDBに差し替えれば使えるみたいな単純な話ではないところが厄介ですが、ちゃんと勉強して使いどころを見極めれば非常に心強い味方になってくれるでしょう。

終わりに

引き続きLambdaの話を続けます。

2018年4月2日月曜日

【AWS Lambda】帳票出力API開発 その1

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。



上記に記載したとおり、最近覚えたPythonをメインに使用して社内用のWebシステムを作ってみました。
システム構成はこんな感じです。




複数のアーキテクトから構成されるシステムですので、このブログでは分解して連載して行きたいと思います。

最初はAWS Lambdaで稼働する帳票出力APIです。

AWS Lambda

AWS Lambdaは、Lambdaが提供するコード実行環境です。
公式サイトはこちら。


公式サイトにはこのように書かれていますね。

AWS Lambda はサーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービスです。AWS Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケーリングします。使用したコンピューティング時間に対してのみお支払いいただきます- コードが実行中でなければ料金はかかりません。AWS Lambda によって、実質どのようなタイプのアプリケーションやバックエンドサービスでも、管理なしでコードを実行できます。

でもこれ、初めてLambdaに触れる人には何言ってるのかチンプンカンプンだと思います。
そこでまずはLambdaの導入編として、その使い方や長所、短所といった解説から行ってみましょう。

特徴1:サーバレス環境である

サーバレス環境、サーバレスアーキテクチャ……。
最近のクラウド界で流行のキーワードです。

サーバレスとは直訳すれば「サーバが無い」という意味になりますが、実際のところ、サーバはあります。

あくまで我々利用者がサーバの細かい設定を意識しなくて良い、利用者目線でサーバが無いかのように見える、という概念的な話です。

概念的な話なのでぼんやりとしてしまいがちですが、この画面を見るとピンと来ると思います。




これはLambdaの管理画面で、ソースをアップロードする項目です。

画面からお察しのとおり、Zipで圧縮したソースをアップロードするだけで実行可能な状態になります。

ソースをサーバのどこどこに配置して、そこにパスを通し、Webリクエストを受ける為にapacheやロードバランサの設定も……とか、そういうのは不要です。

Zipファイルをドンと載せるだけで実行可能。サーバ構築不要。
それが「サーバレス」という言葉の意味です。

ちなみにですが、前述のとおり、我々がサーバを意識しないだけで、実際にはサーバはあるんです。
大企業などでは「インフラ担当」「リリース担当」「開発担当」が完全に分かれている場合、開発担当は作ったソースをリリース担当に渡せばそのうちリリースしておいて貰えるという体制が構築されていることがありますが、
この場合、開発担当の視点ではサーバレスということになります。

従来は「インフラ担当」「リリース担当」がやってくれていた作業を自動でやってくれる。
それがLambdaです。

今まで出来なかったことが可能になるわけではありませんが、今までやっていたことが楽に出来るようになります。

一方、人を介在させず全自動でやるために「制約」も色々ありますが、それは徐々に勉強していきましょう。

特徴2:コンピューティング時間課金

特徴その2は、コンピューティング時間課金であること。

普通のレンタルサーバを借りる場合、月3000円でサーバ1台をレンタル、とかそういう課金方式です。

Lambdaはソースが動いた時間で課金されるので、ソース実行時間が1秒だったら1秒だけ課金されるという方式です。

「じゃあ、1日1度、夜間に3秒で終わるファイルクリーンアップバッチを実行したい場合、1日3秒。月90秒の時間だけお金払えば良いってこと?」

と問われれば、そのとおりです。
そういうところで長所を発揮するサービスです。

軽微な処理の為にサーバを1台占拠したり、既に動いているサーバの隅っこにこっそり置かせて貰ったりとか、そういうのは必要ありません。

軽微な処理だけの為の独立した環境が手に入るという、疎結合という観点でも優れたシステム設計を実現出来ます。

しかし、それ故の欠点もあります。

何故「処理が動いた時間だけ課金」という事が可能なのかというと、それは動いていない時間帯は裏側にあるインスタンス(=サーバ)が寝ているからなのです。

ずっと起きっぱなしだったらAWS側のリソースを食ってしまいますので、無課金というわけにはいきません。
使っていない時間帯は寝ているからリソースを食わない。従って、寝ている間はタダでOK。
そういうカラクリなのです。

だから、寝ぼけた状態から起きる為のコスト、「スタートアップ時間」が発生します。

これが決定的に向かないのがJavaです。
Javaは初期起動でJavaVMを展開するコストが重く、その後もクラスロードが重いと、とにかく最初が重い言語です。

最初が重い言語であるにも関わらず、Lambdaでは起きる度にスタートアップを要求される。
致命的に相反する性質です。

でも実は、今回開発した帳票出力APIはJavaで作ってしまいました。
何故Javaなのか?
それはJavaのライブラリを使わなきゃ実現出来なかったからです。(泣)

事情は後の連載で明らかになりますが、私は好きでLambdaにJavaを展開したわけじゃないってことはご理解下さい。

ちなみに、元々はJavaエンジニアである私が最近Pythonに手を伸ばした理由の一つとして、コレがあります。


  • スタートアップが遅いJavaでは、これからのクラウド時代に適合し切れない


と、私は考えています。

Java自体は良い言語で、今後もずーっと使われていく絶対的安全牌の言語だと思います。
しかし、Javaしか出来ないってエンジニアはヤバい。
Javaの欠点を補える性質を持った言語を身につけておかないと、使い回しの効かないエンジニアが出来上がる危険性があると思います。

そういうわけで、今までJavaだけやってきたエンジニアは、これからの時代の変化に対応する為にPythonを勉強していくことがオススメです。

続く

Lambdaで紹介することはまだまだあります。
次回に続きます。

2018年3月26日月曜日

code-prettifyで技術ブログの可読性アップ

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

今回はちょっと臨時番外編をお送ります。

サイトが見辛い

最近はQiitaという技術交流SNSが注目を集めていますよね。
私も技術調査を行っている時にQiitaに掲載されている記事にお世話になることが多いです。

それを見ていて思うのが、何かこのブログって掲載しているブログが見辛いなぁ。。。




このブログを始めた2013年当時、私はGoogleが提供してくれているコード掲載用ライブラリである「code-prettify」を導入したのですが、
今となっては明らかにQiitaとか他の技術ブログより見辛いぞ。

一体どうなってんの???

と言うことで、現状に甘んずることなく、ブログの品質向上を目指して見直しを行うことにしました。

何か良いライブラリ無いかな。。。

code-prettifyだった

そして調査して分かりましたが、私のやりたいことは「code-prettify」で出来るんですね。

code-prettify自身が2013年当時から進化していて、最新版を持って来れば良いんですよ。

2013年の頃はGoogle本家に置いてあったと記憶しているcode-prettifyも、今はGitHubに引っ越ししているようです。


今まで使っているcode-prettifyを消して、新しいのを入れなおしてみましょう。

run_prettify

run_prettifyはAjaxライブラリの一種なので、HTMLのヘッダーで宣言が必要です。

以下のようにCDN(コンテンツデリバリネットワーク)の以下を宣言して下さい。

<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"></script>


CDN……。
要するに、Googleの親サイトに直接繋いでJSファイルを読み込むわけです。

便利である一方、Googleのサイトが落ちたり、無くなっちゃったりすると死んでしまうわけですが、run_prettifyはCDNを使った方が良いと思います。

容易な変更が許されない業務システムで使うライブラリであれば、そのシステムをリリースした時のバージョンを維持する為にJSファイルをローカルにダウンロードしてシステム内部で保持する必要があります。
でも、このブログって業務システムではないですし、何より新しさが重要ですから。

CDNが無くなったり、引っ越ししたりしたら、それに合わせてブログを更新するべきだと思います。
更新が遅い技術ブログなんて役に立たないっしょ?

何年も前に取得した古いライブラリを維持するとかは業務系システムで考えるべきことで、こういうブログは目新しさを求めてCDNを呼べば良いと思います。

さて、「run_prettify.js」ですが、これで描画に必要なスタイルシートとかも全部読み込んでくれています。

ですが、読み込む際にオプションを指定することが出来ます。




いくつかありますが、気になった所を挙げてみましょう。


  • autorun:自動実行。画面のonLoad時に自動実行することで、デフォルトはtrueです。どうも昔は自動実行が無くて、自分でonLoad実行しなきゃいけなかったようですが、今はこのとおり、自動実行でラクチンです。
  • lang:プログラミング言語の指定。code-prettifyは「Java表示モード」「Python表示モード」みたいに、言語毎にグラフィックを変えてくれるというIDEみたいな凄い技をやってくれます。そのデフォルト言語ですね。デフォルト言語をPythonにしておけば、何もしなければPythonモードで表示され、その上でJavaにしたい時はHTMLの中のclassにJavaを指定すればそこだけJavaモードになります。
  • skin:スキンの指定。後述。

大事なのは「skin」かな。




上記のページにあるスキンからお好みのものを選ぶことは出来ます。
当ブログは長らくdefaltでしたが、今回を期に「Sons-Of-Obsidian」に変更します。



<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js?skin=sons-of-obsidian"></script>



これで宣言完了。

書く

ここから先の使い方は簡単です。
例えばPythonのコードを載せたい時は、以下のようにHTMLを書けばOK。

<pre class="prettyprint linenums"><code class="language-python">...コード...</code></pre>

「linenums」とは行数を表示するオプションです。
特に理由が無い限りは常につけておいた方が良いでしょう。

実際、このやり方で上記の画像の状況だったソースを掲載すると以下になります。


import os
import json

dirPath = 'C:/MyMail_result'
files = os.listdir(dirPath)

#連想配列を作成
map = {}

#ファイルを全部読み込み
for file in files:
    f = open(os.path.join(dirPath,file))
    data = json.load(f)
    f.close()

    #name毎にsalienceを集計
    for entity in data['entities']:

        name = entity['name']

        if name in map:
            map[name] = map[name] + entity['salience']

        else:

            map[name] = entity['salience']

#集計結果をソート
resultList = reversed(sorted(map.items(), key=lambda x:x[1]))

#出力
for data in resultList:
    print(data[0] + '\t' + str(data[1]))

これこれ。
これをやりたかったんですよ。

今の時代なら絶対コレしか無い!!

終わりに

よっしゃ。これで綺麗になったぞ。
やっぱね、5年も同じブログを続けていると時代遅れになっている部分があったとしても、どうしても「これでいいや」って気分になりがちなんですよね。
今までそれでやって来ているわけですから。

でも、偶にで良いので振り返って、「いやいや、今ならもっと良いやり方があるぞ」という所を見つけたら、改善を決行しなければなりません。

「今までそれでやって来た」というだけで改善を行わないという怠慢!!

ブログ運営に限らず、業務を行う上では常に気を付けていきたいものです。