上記に記載したとおり、最近覚えたPythonをメインに使用して社内用のWebシステムを作ってみました。
システム構成はこんな感じです。
複数のアーキテクトから構成されるシステムですので、このブログでは分解して連載して行きたいと思います。
最初はAWS Lambdaで稼働する帳票出力APIです。
AWS Lambda
AWS Lambdaは、Lambdaが提供するコード実行環境です。
公式サイトはこちら。
公式サイトにはこのように書かれていますね。
AWS Lambda はサーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービスです。AWS Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケーリングします。使用したコンピューティング時間に対してのみお支払いいただきます- コードが実行中でなければ料金はかかりません。AWS Lambda によって、実質どのようなタイプのアプリケーションやバックエンドサービスでも、管理なしでコードを実行できます。
でもこれ、初めてLambdaに触れる人には何言ってるのかチンプンカンプンだと思います。
そこでまずはLambdaの導入編として、その使い方や長所、短所といった解説から行ってみましょう。
最近のクラウド界で流行のキーワードです。
サーバレスとは直訳すれば「サーバが無い」という意味になりますが、実際のところ、サーバはあります。
あくまで我々利用者がサーバの細かい設定を意識しなくて良い、利用者目線でサーバが無いかのように見える、という概念的な話です。
概念的な話なのでぼんやりとしてしまいがちですが、この画面を見るとピンと来ると思います。
これはLambdaの管理画面で、ソースをアップロードする項目です。
画面からお察しのとおり、Zipで圧縮したソースをアップロードするだけで実行可能な状態になります。
ソースをサーバのどこどこに配置して、そこにパスを通し、Webリクエストを受ける為にapacheやロードバランサの設定も……とか、そういうのは不要です。
Zipファイルをドンと載せるだけで実行可能。サーバ構築不要。
それが「サーバレス」という言葉の意味です。
ちなみにですが、前述のとおり、我々がサーバを意識しないだけで、実際にはサーバはあるんです。
大企業などでは「インフラ担当」「リリース担当」「開発担当」が完全に分かれている場合、開発担当は作ったソースをリリース担当に渡せばそのうちリリースしておいて貰えるという体制が構築されていることがありますが、
この場合、開発担当の視点ではサーバレスということになります。
従来は「インフラ担当」「リリース担当」がやってくれていた作業を自動でやってくれる。
それがLambdaです。
今まで出来なかったことが可能になるわけではありませんが、今までやっていたことが楽に出来るようになります。
一方、人を介在させず全自動でやるために「制約」も色々ありますが、それは徐々に勉強していきましょう。
普通のレンタルサーバを借りる場合、月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だけやってきたエンジニアは、これからの時代の変化に対応する為にPythonを勉強していくことがオススメです。
次回に続きます。
そこでまずは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で紹介することはまだまだあります。次回に続きます。
0 件のコメント:
コメントを投稿