AWSと自動化で顧客とサービス運用に寄与し自分たちも楽に　ラクスのインフラエンジニアが自動化にこだわる理由

なぜAWSを多用するのか

柏木達仁氏（以下、柏木）：楽楽労務の担当をしている柏木達仁と申します。今回のテーマは、インフラから「積極的にAWSサービスと自動化を使ってtoBのSaaSをローンチしたその後」というテーマで発表します。よろしくお願いいたします。

自己紹介です。私は2010年に新卒で入社して、SIerだったのですが、パッケージシステムやSaaSに関わっていました。2017年にご縁があってラクスに入社して、インフラ開発部に所属しています。主にblastmailというサービスや今回の楽楽労務など、AWS関連のプロダクトを担当しています。

好きなことは、ラクスの名前に従って、楽なこと。あとは考えてやることですね。嫌いなことは、繰り返すとか伝言ゲームみたいなことです。

今回のアジェンダですが、SaaSにおける運用について、ちょっとSIerの運用プロジェクトとは違った面があるので、そこを簡単に紹介したいと思います。あと、なぜAWSを多用するのかというところについて。3つ目はAWSサービスの選定のポイントについて。そこからちょっとつながっていきますが、なぜ自動化をするのか。あとは事例として、バージョンアップにおける自動化をお話しします。

SaaSにおける運用とは

SaaSにおける運用とは何でしょう、と言ったときに、1つ大きく特徴としてあるのが、サービスを提供し続けるための業務。ちょっとざっくりしていますが、SIerであれば納品して終わりみたいなところがありますが、SaaSの場合はそうではなく、その後がスタートラインです。ローンチしてからがスタートライン。そこからがサービスとしての勝負になってきます。

そして絶対にある運用業務の1つに、バージョンアップがあります。

そんな中で、なぜAWSサービスを多用するのかですが、オンプレミスよりも、圧倒的にイニシャルコスト、つまり初期コストが安い点が挙げられます。オンプレミスでデータセンターを契約して回線を引いて、サーバを発注してラッキングして……というよりも圧倒的にイニシャルコストが安いです。

あと、売れるか売れないかわからない、利益が出るかわからないところで、そういった“考えなくてはいけないコスト”も減らせるのが1つ目です。とくにローンチして間もない楽楽労務の場合は、リリースしたら、早い段階でお客様に提供して早く反応を確かめたいフェーズにおいてはスピードが重要です。簡単に言うと、開発が終わっているのにインフラが準備できていないという状態は、なるべく避けたい。

3つ目の理由は、リソースはある程度お金ですぐ買えます。今言った話に近いのですが、見積もっていたよりもサーバリソースがもっと必要だった、もしくは思っていた以上に売れているときに、お金ですぐにサーバリソースを買えるのは、メリットとしてすごくあります。あと、AWSは世界ナンバーワンなので、基盤の信頼性が高いというのもあります。

AWSサービスをどう考えて選定するのか

こういったAWSサービスを多用する中で、AWSサービスは今だと160、170ぐらいありますが、このAWSサービスの中でどう考えて選定しないといけないかを3点ほど挙げたいと思います。

1つ目は、使うAWSサービスは、やたらと増やさないのがけっこう大きなポイントかなと思っています。

わかりやすくいうと、自分たちに既にある程度ノウハウがあるものの代替を使う。例えばRDS、データベースマネジメントサービスですが、ここでPostgreSQLの技術があるなら、そのままPostgreSQLやAuroraを使う。AuroraのPostgreSQLバージョンを使う。あえてドキュメントDBみたいなMongoDBにいかないという選択肢です。

あとは、やたらとサービスを増やしていくと、どうしても構成図を人間が認識できないよね、書けないよねというレベルになってしまうこともあります。なので、「シンプルイズベスト」を心がけていきましょう。AWSサービスをやたらと増やさないというのが1つ目のポイントです。

2つ目は、サービスごとに何に対する課金か、従量課金などを気にしなければいけない。ちょっと今言った2つに関しては、あとで例をあげます。

3つ目は、後半の自動化についてもつながっていくことですが、インフラのコード化、自動化も考えている、といったところです。

間違った選定や使い方をするとどうなるか

間違った選定や使い方をするとどうなるか。例えば、ALB、ECS、RDSでいいものをあえてAPI GatewayとLambdaを組み合わせると、学習コストが高くなりがちですよね。それに、インフラエンジニアの中で、このAPI GatewayやLambdaを使って十分に運用経験した人間は、おそらくパーセンテージ的にかなり低いんだろうなと思っています。

前者で挙げたALB、ECS、RDSは、Web、AP、DBの3層構造、いわゆる一般的なWebアプリケーションの仕組みに近いので、学習コストはかなり低いと思っています。2つ目のこれが、何によって従量課金されているのかをしっかり把握しましょうというところで、わかりやすい例がS3かなと思います。

S3ストレージ容量と通信料の従量課金だと思っていたら、クエリ回数でも課金されている。アプリから無駄にS3をlsしたり、リストにするみたいなところにバグなどがあると、とんでもない料金が月末に請求されて、「なんだこの料金は？」という話になってしまいます。

わかりやすい例でS3を出しましたが、自分たちが使うAWSサービスが何によってお金を取られているのかをしっかり把握して、開発者と認識を合わせていくのが大事なポイントです。

結果、楽楽労務は簡単にいうと、このような構成になっています。ALB、アプリケーションロードバランサがあって、ECSがあってAuroraがあるというのが、ほぼ主軸です。補助的に下の部分も使っていますが、おおむねメインはALB、ECS、RDSでできています。

なぜ自動化していくのか

後半のテーマは、なぜ自動化していくのかです。冒頭でも赤字で書きましたが、SaaSでは絶対にバージョンアップが発生するので、自動化したいというモチベーションがあります。そして、安定して継続させるためには、属人化の排除も必要になってきます。

私がとくに意識しているのは、人間の品質。コマンドを叩くなどの手作業したりすると、やはりブレというものが発生しますが、コード化していくことによって、ブレがほぼ消えていきます。作ったコードを向上させていけば、品質は自ずと上がっていくと考えています。

ここからが事例になります。楽楽労務でどうやってバージョンアップを行っているかについてです。一番左は「ランデック（RUNDECK）」と読みます。真ん中は「テラフォーム（Terraform）」と言います。あとはAWSとなっています。Terraformはけっこう有名なツールなので、ご存知の方も多いのかなと思います。

Web UIからスクリプトを定義して実行できるツール「Rundeck」

ツールの紹介になりますが、RundeckはJava製で、Web UIからスクリプトを定義して実行できるツールです。スクリプト型のものであれば、ほぼ何でも実行できます。スケジュールだったりボタン実行だったり。次が特徴なんですが、実行履歴が残る。ユーザーへの権限制限があるので、監査とかB to B向けで、けっこう強いと思います。

おすすめの動画として、Rundeckを作っている会社が出しているYouTubeのリンクを貼りました。QRも同じ場所になっています。この辺興味のある方はご覧いただければと思います。

このRundeckのジョブの実行画面を紹介します。これはアプリケーションをデプロイするRundeckのジョブになります。真ん中にimgtagと書いてありますが、ここにコンテナのイメージのタグを指定して、右のほうにある「今すぐジョブを実行」を押すと、ECSのタスク定義が書き変わって、そしてアプリケーションコンテナが差し変わる仕組みになっています。

これだけなので、ほとんどコピペができて、ボタンが押せれば誰でもできる状態になっています。これがRundeckの簡単な説明です。

クラウドの構成管理ができるInfrastructureコードツール「Terraform」

次にTerraformというツールは、Golangで書かれています。クラウドの構成管理をできるInfrastructureコードツールの1つです。HashiCorp社という、けっこういろいろなツールを開発している有名な会社さんが作っています。

最初からTerraformを使っていないとコード化できない、というわけではなくて、有志が既にあるAWSリソースをコード化するツールを作ってくれています。

たまに聞かれることですが、Ansibleよりも、OSより下のレイヤーを扱いやすいと思ってTerraformを使っています。AnsibleはOS以上のレイヤーに強いという肌感覚があったので、OSより下のところはTerraformで、となっています。こちらもおすすめの動画のリンクを貼ります。

今あるAWSリソースを補助のOSSツールを使って出すと、こんな感じのコードになりますという例を出してみました。完全にサンプルです。一度AWSを使ったことがある方ならば、amiが何か、availability_zoneが何かなどは、想像がつくかなと思います。

自動化が顧客とサービス運用に寄与する

こういったRUNDECK、Terraform、AWSを活用することで、バージョンアップの際にインフラのコード、Infrastructure as Codeを変更する、テストする、あとはボタンを押すのみでバージョンアップが完了します。これによって一定の作業品質を保ちながら非属人化し、手順書を作ってレビューして、といったリードタイムの準備時間を最小化できます。

これによって顧客とサービス運用に寄与します。サービスがよりよくなって、お客さんにも早くものが提供できて、それによって、我々としても改善すべきところを早く改善していける。スピード感をすごく重視して運用する仕組みを作るために、自動化をしています。

あくまでも、このバージョンアップにおける自動化は一例であって、他にも自動化は楽楽労務に限らず進めていっています。やはりインフラエンジニアをしていると、どうしても作業が手動になっていて、人間としてのブレが発生して、そこでヒヤリハットが発生したり。そうすると、せっかくがんばっているのに、ミスにつながったりしてしまいます。

また生産性も手作業だとなかなか上げづらい。そういったところは、バージョンアップにおける自動化は1つの例ですが、自動化を進めて生産性を上げて、また属人化をなくしてミスをなくしていく、というところを目指して日々運用をがんばっています。

最後になりますが、宣伝です。一緒にプロダクトをよりよくしていって、また生産性を高く働きたい。自動化で楽にお仕事していきたい。それによってお客様のビジネスにも貢献したり、エンジニアとしてそういう働き方をしていきたい方を常に募集しています。ご清聴ありがとうございました。

質疑応答

司会者：1個チャットで質問いただいていますね。「オンプレミスではなくAWSにすることでコストは下がりましたか？」という質問です。

柏木：今の時点で言うと、下がっていると思います。このあともっと大きくなっていくと、そのモデルとの試算の比較が必要だと思いますが、今の時点で言うと、ほぼAWSのほうが安く運用できているのかなと。人件費の部分も含めてそう考えています。

司会者：もう1個、質問がきています。「GCPやAzureもある中、AWSを採用した理由をうかがいたいです」とのことです。

柏木：それで言うと最初に鈴木さんの発表にあった、技術選定の前身の取り組みでAWSを使って技術検証などをしていたことも、すごく大きな理由としてあります。なので、その結果があって、ほぼAWS一択で選ばれています。

司会者：途中でも話していましたが、やはり学習コストがけっこう大きな要因になってきて。

柏木：そうですね。インフラをやっていると、「あぁ、あれがこれになっているのね」と、けっこう変換が効くんですけど、やはりアプリケーションをメインでやっている方は、AWS用語に置き換わる、プラス普段触っていないインフラ概念に名前も変わるので、正直コストとして高いのかなと思ったりもします。

司会者：情報量も、GCPとかAzureに比べるとAWSのほうが多かったりするんですか。

柏木：そうですね。いろいろな記事を見ていくと、「AWSと〇〇を比較してみた」系の記事なり情報なりは、圧倒的に多くて。なのでやはりAWSというのはいいのかなというのと、あとすごく細かな点で言うと、GCPやAzureは、外部にメールを送るのにちょっと手間がかかるんですね。実は外向きの25番ポートに直接アクセスできない制約があったりとか。AWSも手放しにできるわけじゃなくて、ちょっと申請とかがいるんですけど。

そういったところも含めて、より自由にクラウドを使っていくには、実はAWSさんのほうがよくて。やっぱりシェアがあるので、その分強いというのは正直感じます。

司会者：なるほど。そういう補足的なモチベーションもあるということですね。

柏木：そうですね。

司会者：もう1つの質問が来ていますね。「ECSノードはFargateとかを使っているんでしょうか？　それともon EC2でしょうか？」。

柏木：Fargateですね。

司会者：それはなぜ？

柏木：数年前に鈴木さんと検証していたとき、まだFargateのサービスがなかったので、on EC2で技術検証をしていたのですが、正直言うとon EC2は、「自分でEC2を立ててDocker Composeでも書いたらいいんじゃない？」と思う内容だったのが、Fargateというサービスができて、だいぶコンテナ的にコンテナサービスとして確立してきているなというイメージはあります。

司会者：ありがとうございました。