Tech Blog

グローバルな家族アプリFammを運営するTimers inc (タイマーズ) の公式Tech Blogです。弊社のエンジニアリングを支える記事を随時公開。エンジニア絶賛採用中!→ https://timers-inc.com/engineering

マイクロサービスとAWS Lambdaの今

初めまして。
Timers、サーバアプリケーション担当のzumaです。
普段は主にPHPでのアプリケーションサイドの構築を担当しておりますが、
先日、AWS re:inventに参加させて頂きました!

re:inventとは、AWSの主催する、5日間に渡ってラスベガスで開催される一大イベントで、 AWSに関する基本的な使い方から新製品発表、上級者向けのTips、果ては内部構造やサービス誕生秘話まで 多種多様なセミナーが毎日数十と開催され続け、AWS内部の方から公認パートナー、ユーザと言ったあらゆる 人が、好き放題AWSのサービスについて学ぶ事が出来るという素敵なイベントです。
(来年からは、ラスベガスの開催では無くなるという噂があります。)

英語もインフラの知識も余り自信の無い状態での参加でしたが、 1週間AWSに関するセミナー漬けの日々を送らせて頂いたお陰で、様々な知見を得る事が出来ました。

既にご存知の方も多いかと思いますが、 とにかく今回のre:inventのキーワードは、「サーバーレスアーキテクチャ」と、その実装手段である「lambda(ラムダ)」でした。

他のレポートでも、新機能等の詳細は多々記載されていると思いますので、 ここでは、各技術の登場背景や、大まかな使いどころと言った少々粒度の大きな概念についてまとめさせて頂こうと思います。

そもそも、何故今「サーバーレスアーキテクチャ」が注目されているのでしょうか?

歴史的経緯(アジャイル)

少々遡りますと、アジャイル開発という言葉が非常に流行りました。
今では、流行り言葉では無く、先進的なIT企業に於いては当たり前となり、その為の手法論に注目が集まるに至っています。
(例えば、今回のre:inventでも、AWS code pipelineやAWS cloud formationといった、アジャイル開発に必要なCI/CD系のサービス強化が数多く発表されました。)

そんなアジャイル開発に於いては、4~5人のチームの中で、スプリントやデイリー単位で様々な決定を下す必要があり、一つのサービスに対するチームの数は複数ある事も一般的です。

アジャイルの突き当たる問題とマイクロサービスによる解決

各チームの独立性は、アジャイルの一つの肝と言っても過言では無いかと思いますが、その場合、チーム間での設計方針の違い等はどの様に吸収されるべきでしょうか?
それぞれが思い思いにやっても、結果、自動テストとバージョン管理システムによって解決されると期待出来るのでしょうか?
それとも、コードのうち共有される部分に関しては、チームの意思を超えた全体会議やTopDownに頼るべきなのでしょうか?

上記は両方とも現実的な手法としてしばしば現場で行われてきたと思いますが、そこに登場した第三の選択肢こそ「マイクロサービスアーキテクチャ」です。

マイクロサービスでは、各機能をAPI越しの徹底的に疎な結合とします。
それによって、各チームがAPI仕様を共有するだけで理論上上記の問題が解決します。

マイクロサービスとサーバーレス

但し、マイクロサービスには幾つかの欠点があります。
一つには、チームの独立性を尊重する方針を貫いた結果として、高い属人性が生まれてしまう事です。
基本的には、あるチームが開発した機能は、そのチームがメンテナンスを続けていく必要があります。
もう一つは、各マイクロなサービスが、それぞれ独自にインフラ整備等の根本から実装されなければいけない事によって 開発工数が上がってしまうという事です。

この後者の問題点に関してのソリューションこそ、「サーバーレスアーキテクチャ」なのです。
(前者の問題点に関しては触れません。そして本題に戻ってくるまでに大分行数を割いてしまいました。) サーバレスアーキテクチャとは、
SaaSやBaaSを徹底的に活用する事で、マイクロサービス毎のインフラ整備コストを削減しよう。」という意図に基づくアーキテクチャです。
AWS lambdaとは、正にそういった意図に基づき、インフラ管理を意識する事なく、スケーラブルなWeb APIを構築することが出来るサービスなのです。

導入の検討にあたって

では、ここからは、そんなマイクロサービスアーキテクチャとlambdaに関して、導入を検討する際に最初に考えなければならない事に関して、幾つか整理していこうと思います。

  1. lambdaの特徴は?
    lambdaは、各種AWS上のイベント(例:S3へのストア、API gatewayへのアクセス)をトリガーとして実行されるイベント駆動のプログラムのクラウド上の実行環境です。
    lambdaは、各APIアクセスが強い独立性を持って実行されます。
    lambdaは、Node.js、pythonJavaで書くことが出来ます。また、C#対応も発表されました。但し、Javaに関しては起動オーバーヘッドの関係で非常に遅いと言われています。

  2. lambdaの弱点は?
    lambdaは、今のところ同時実行数が「AWSアカウント単位で100(それ以上は別途事前申請)」なので、ある程度立ち上がっていたり、アクセスが見込めるサービスでは
    ユーザやフロントアプリから直接callされるAPIとして使う事は難しいです。
    また、「コネクションプーリングしないので、RDSへのアクセスは苦手(普通にやると沢山コネクションが貼られる)」と言ったデメリットもあります。
    回避策はある様ですが、「DBはDynamoDBを選択するのが一般的」と考えておいて間違いありません。

  3. 今すぐバックエンドは全てlambdaにすべき?
    いいえ、上述の弱点から、今あるサービスのバックエンドを全てlambdaで行う事は(AWSの中の人談含め)推奨されていません。
    但し、マイクロサービス!=lambdaなので、マイクロサービス化する事自体は、今でも選択肢の一つでしょう。
    例えば、EC2とRDSの組み合わせで作ってもマイクロサービス足りえます。
    サーバーレスとクラウドサーバーの中間世代として、Dockerなどのコンテナを使うという選択肢もあります。
    AWSでも、コンテナを使って簡単にサーバを構築できるelastic beanstalkというサービスが提供されています。

  4. マイクロサービスってどの粒度を指すの?
    人によってかなり見解が異なっている印象を受けていますが、幾つかのトレンドを感じます。

    • 一番小さな捉え方は、「DBの1コレクション(1テーブル)の操作=1lambda=1マイクロサービス」という考え方です。
      これは、AWSのマイクロサービスのサンプルやスケルトンでも度々登場する構成ですが、(railsMVCのMの様に)ちょっと実装に寄り過ぎてしまって本質を外している構成かと思います。
      また、RESTfulが徹底されていない場合には、APIの置き場に困ることになりそうです。
    • 次に小さな捉え方は、機能群として切れる単位でマイクロサービスとする考え方です。
      例えばECサイトで言うなら、「カート機能」「決済機能」「認証機能」「商品管理機能」と言った感じです。
      最もマイクロサービスらしいマイクロサービスですが、綺麗に切り分けないと、実装が物凄く大変になりそうです。
    • 一番大きな捉え方は、ユーザに明確に価値を持つサービス単位です。
      例えば不動産サイトで言うなら、「戸建購入サービス」「マンション購入サービス」「賃貸サービス」と言った感じです。
      (マイクロサービス区分けに関する)設計難度は低そうですが、上述したマイクロサービスの登場背景から考えるとちょっと違う感じがします。

結局、「粒度自体もチーム次第、サービス次第でバラバラで良い」というのが、マイクロサービス構成の登場経緯に適合しているのかも知れません。
(但し、マイクロサービス同士の多層構造になってしまうと独立性が損なわれてしまうので、そこだけ注意が必要でしょう。)

まとめ

以上、如何でしたでしょうか?
AWSの世界中のエンジニアに触れて感じた、「マイクロサービスの今」を少しでも感じて貰えたならば嬉しいです!


また、弊社では、子育て家族アプリFamm、カップル専用アプリPairyを運営しており、現在エンジニアを積極採用中です! 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください! 採用HP : http://timers-inc.com/engineerings

Timersでは各職種を積極採用中!

急成長スタートアップで、最高のものづくりをしよう。

募集の詳細をみる