みなさんこんにちは！ワンキャリアでソフトウェアエンジニアをしている中野です。 私がワンキャリアに入社して、早いもので3ヶ月が経ちました。 私は前職でもエンジニアとして活動していましたが、今回は、この3ヶ月で私がどのような業務に携わり、組織に対してどのような印象を抱いたのかの振り返りをお届けします。

はじめに 普段はRuby, PHP, Typescriptを主に使ってアプリ開発をしているITエンジニア4年目のY.Mです。 AWSを勉強していく中で、「サービスめっちゃ多い」とか「どんな用途で使えばいいか毎回忘れる・混乱する」なんて経験ありませんでしょうか？ また、実際にAWSを触ってみて、VPC・ECS構築やCI/CD自動化などで「今自分って何でこの操作しているんだろう．．．」と思うことありませんでしょうか？ 自分はもうすぐ社会人4年目を終えるところで、AWSもちょこちょこ触ったりしているのですが、あまり頻繁に構築したりもしていないせいか、悲しいことに忘れてしまうこともかなり多いです。 そこで、どうしたらAWSを包括的にかつ長期的に概念を覚えられて、実務にも活かせるんだろうと考えていました。その時に思いついたのが、今回執筆する AWSの全体像をスーパーマーケットに例える という内容です。身近なものに例えて、脳に長期記憶を促そうといった狙いです。 今回の記事は、 AWSの基本構成を包括的に理解したい AWSの概念を長期記憶化したい といった初級者向けの記事になっています。 私は、実務ではCloudWatchでのログ監視やS3バケットへのデータ格納は使っていますが、正直AWSの理解が断片的であったり、1からAWSサービスを構築した経験はほぼないので、これを機にAWSのサービスを包括的に覚えてみようと思いました。私も実際にこの例えを活用したことで、AWSに対する全体の理解が一気に深まりました。 今回、身近なものに例えていくため、厳密な定義ではないところもあるかもしれませんが、この記事にて 「包括的」かつ「長期的」 にAWSサービス全容の大枠な理解が深まれば幸いです。 AWSの学習ロードマップ 今回、AWSの全体像を掴んでいくにあたって、 AWS学習ロードマップ （制作者 くろかわこうへいさん、小山雄太さん）が非常に有用だなと思ったので、こちらを使って解説していきます。 上記URLから、PDFでAWS学習ロードマップをダウンロードできます（営利目的の使用は厳禁と記載があります）。 こちらの学習ロードマップですが、全部でセクション数が12個あり、大きく3つに区切ると綺麗かなと思ったので、3つに分けてそれぞれ図解も交えて解説していきます。 AWSの基本構成 （Section 7まで） サーバレスなサービス導入 （Section 10まで） 分析・マルチアカウント作成 （Section 12まで） AWSの基本構成 (〜Section 7) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例 (サービスはめ込み版) 解説 ここでは、スーパーマーケット、隣接する工場やオフィス、そして面している道路を使ってサービスの解説をしていきます。無色・薄い灰色のエリアがパブリック空間（一般市民が出入りできる空間）・濃い灰色のエリアがプライベート空間（専用の人間しか入れない空間）になっています。 AWS（Amazon Web Service） 概要：Amazonが提供するクラウドコンピューティングサービス 例示：地域全体 AWSは、Amazonが提供するクラウドコンピューティングサービスで、シェアNo.1を誇っています。 AWS空間にて、サーバーの構築・管理までを一貫して管理する集合体になります。 実世界では、地域全体と同等になるかと思います。 Route53 概要：ドメイン名を検索してIPアドレスに変換するサービス 例示：自動車のカーナビ Route53は、ドメイン名をIPアドレスに変換することで、コンピュータ内部で通信できるようにする役割を持っています。 例えば、「mynavi.jp」が入力されたら、「3.165.11.119」といったように変換されて通信されます。 これが、実世界では自動車のカーナビ（目的地名を入力し、ナビでもわかるようにピン表示へ変換する）でも同様なことが言えると思いました。 CloudFront 概要：コンテンツを近くから配信し、高速通信を可能にするサービス 例示：配送センター CloudFrontは、コンテンツを近くから配信することで、低遅延・データ転送性能向上を可能にするサービスで、コンテンツをキャッシュする役割を持っています。 実世界では、配送センター（中継所）のようなイメージで、遠方の倉庫から運搬してきた荷物を配送センターで保管し、必要な時に配送センターから届けることで、より短い時間で出荷可能になるのと同様になるかなと思います。例えば、スーパーで発注した食材が必要になった時に、倉庫（県外にあるとする）から出荷すると運送時間に比例して、鮮度やおいしさが落ちてしまうリスクがあります。ただ、配送センターから出荷を行うと、短い運送時間で出荷ができるため、新鮮な状態で食材を届けられるというイメージです。 ACM（AWS Certificate Manager） 概要：SSL/TLS証明書を管理できるサービス 例示：公認バッジ ACMは、SSL/TLS証明書を発行・更新・管理することで、安全な通信の一助を担うサービスになっています。 先ほどの配送センターの場合、配送センター自体が本物なのか、或いは悪徳業者が運営しているのかといった見分けが一般市民からは分かりません。そのため公認バッジを発行することで、本物・信頼の証であることを証明でき、安心安全な運送が提供できることを市民へも理解させることができます。 S3（Simple Storage Service） 概要：データを保存・取得できるストレージサービス 例示：倉庫 S3は、静的なデータ（ファイル・画像など）を保存・取得できるストレージサービスです。 実世界では、巨大な倉庫に例えるのが妥当です。 VPC（Virtual Private Cloud） 概要：専用のプライベート仮想ネットワーク 例示：スーパーマーケットの敷地内全体 VPCは、論理的に分離されたプライベートの仮想ネットワークです。この中で、EC2やRDSなどの個人情報が絡むサービスを設計していきます。 今回は、スーパーマーケットの敷地内全体が、プライベートの仮想ネットワークに該当します。 以降のサービスは、VPC内のサービス（スーパーマーケット内）を中心に解説をしていきます。 Internet Gateway 概要：VPCの内外間で通信を行うサービス 例示：スーパーマーケット駐車場出入口（警備員） Internet Gatewayは、VPC内部とインターネット間を通信するためのサービスです。 グローバルIPアドレスをプライベートIPアドレスへ変換し、セキュリティ機能を担保しながら通信する役割を持っています。 実世界に例えると、スーパーマーケットの駐車場の出入口に該当します。この出入口付近で警備員が立っており、怪しい市民を排除することで、スーパーマーケット内の安全性を高めています。 Public Subnet 概要：ブラウザから直接アクセスすることができる領域 例示：スーパーマーケットの商品陳列エリア Public Subnetは、ブラウザから直接アクセスできる領域になります。 実世界では、スーパーマーケットの商品陳列エリアに該当します。ブラウザを世界中の人間の集まりだとした時に、スーパーマーケットで通常の人間が入れるエリアは限られていて商品陳列エリアは入れるものの、従業員専用のバックヤードや有人レジの中には入ることができません。 Private Subnet 概要：ブラウザから直接アクセスすることができない領域 例示：スーパーマーケットのレジ（捜査側）・従業員専用部屋 Public Subnetに対して、Private Subnetはブラウザから直接アクセスできない領域になります。 実世界では、スーパーマーケット内のレジ（操作側）や従業員専用部屋など、一般の人が入れない領域に該当します。 ALB（Application Load Balancer） 概要：サーバに負荷を分散させるためのサービス 例示：レジの案内係 ALBは、サーバに負荷がかからないように適切に通信量を分散するサービスになります。 実世界では、レジの案内係に例えることができます。買い物客が一つのレジに集中的に並んでしまった場合、レジが混んでパンクしてしまいます。それを防ぐために、レジの案内係を用意して、レジへ均等に人が並ぶように調整することで、人の流れを最適化しています。 ECS（Elastic Container Service） 概要：完全管理型のコンテナオーケストレーションサービス 例示：レジ管理人 ※私の調べた限りだと、AWS学習ロードマップの各Private Subnetに置かれているECSはEC2インスタンスであり、それらのコンテナを管理するサービスがECSだったので、それを基に解説します。スーパーマーケット例では修正しています。 ECSは、アプリケーションを動かすためのコンテナを効率的に自動管理してくれるサービスです。 EC2インスタンスへの通信量に応じて、必要なコンテナ（タスク数）を自動増減してくれる役割を持っています。 スーパーマーケットでは、レジの管理人に例えることができて、レジに待つ人に応じて、稼働するレジの台数を増減する指揮官のような役割を果たします。 EC2（Elastic Compute Cloud） 概要：クラウド上の仮想サーバサービス 例示：レジ本体 EC2は、クラウド上の仮想サーバサービスで、アプリケーション本体を動かす根幹を担っています。 スーパーマーケットでは、レジ本体に例えることができて、店舗自体もレジ（売上収集）が存在するからこそ営業することができます。 RDS（Amazon Relational Database Service） 概要：クラウド上の仮想データベースサービス 例示：PC上での売上管理 EC2がサーバであれば、RDSはデータベースサービスになります。 スーパーマーケットでは、レジの売上データに例えることができて、一般人が入れない場所（今回の例では本社オフィスに置きました）で管理しています。 IAM（Identity and Access Management） 概要：役割に対する権限を管理するサービス 例示：スタッフの従業員証 IAMは、役割に対する権限を管理するサービスで、統合管理にあたってセキュリティを強固にする役割を持っています。 実世界では、スタッフの従業員証が該当します。有人レジの操作や従業員更衣室、本社オフィス内部など、一般の人が立ち入ることが禁止されているエリアにて、スタッフの従業員証（IAMロール）が付与されていれば、そのエリアへ入ることができるイメージです。 NAT Gateway（Network Address Translation） 概要：プライベートサブネット内から外部へ通信をするためのサービス 例示：従業員専用部屋（バックヤード）の出入口 NAT Gatewayとは、プライベートサブネットから外部へ通信するためのサービスになり、EC2インスタンスで構築されたアプリケーションから外部APIの接続など、インターネット側で通信したい時に使われます。 実世界では、バックヤードの出入口に該当します。お店の開店前に、レジでの売上金をATMへ入金する時や、発注商品の受け取りなどを行うイメージです。 CodePipeline 概要：CI/CDを自動化するためのサービス 例示：製品組立の現場監督 CodeDeployとは、アプリケーションを自動化するための管理サービスです。GitHubでソースコードの変更を検知したときに、ビルド・デプロイを一貫して自動で行ってくれる役割を持っています。 これを実世界に例えると、依頼された製品の組み立て・取り付けを監督する現場監督員が妥当です。製品の組み立てから取り付けまで一貫してサポートします。 CodeBuild 概要：自動テストやビルドを実行してくれるサービス 例示：製品の組み立て CodeBuildとは、ソースコードの自動テストやビルドを実行してくれるサービスです。 実世界では、現場監督管理のもとで、依頼分の製品の組み立てを行います。 ECR（Elastic Container Registry） 概要：コンテナイメージの保存・共有ができるサービス 例示：完成製品の保管庫 ECRとは、ビルドが完了したイメージの保存や共有ができるサービスになっています。 実世界では、完成製品の保管庫が近いかなと思います。AWS学習ロードマップでは、NAT GatewayとECRがつながっていることより、従業員がバックヤードから出て製品を確認できるようなイメージです。 CodeDeploy 概要：ソースコードの反映を行うサービス 例示：製品の取り付け CodeDeployとは、ソースコードの反映を行うサービスです。 上記のスーパーマーケットの図の例だと、顔認証システムの製品を取り付けているイメージです。 余談ですが、最近AI顔認証決済というものが出てきていて、事前に登録した本人の顔にクレジットカードを登録しておくと、財布やスマートフォンを出さずに登録したクレカで会計ができるみたいです…笑 世の中の進化で、どんどんデジタル化が進むなあと思い知らされます。 https://jpn.nec.com/fintech/face_settlement/index.html CloudWatch alerm 概要：AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービス 例示：異常検知センサー CloudWatch Alermとは、AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービスです。 実世界では、異常検知センサーが近いと思います。レジが混んできて待ち時間が長くなってきた場合に、スーパマーケット内の異常検知のセンサーの作動・放送が行われるイメージです。作動後は次で説明する「SNS」にて解説します。 SNS（Simple Notification Service） 概要：ユーザへメールを送信するサービス 例示：緊急連絡先センター SNSとは、ユーザへメールを送信するサービスを表しており、対策メンバーへの周知を行う役割を担っています。本ケースでは、Cloudwatch alermからアラートを受け取ったタイミングで、メールを送信するような流れになっています。 実世界では、レジの待ち時間が長くなってきた時にセンサーが発動し、緊急連絡先センターに連絡が届き、当該店舗の従業員へ応援を要請するようなイメージです。 Terraform 概要：オープンソースのインフラコード 例示：街を再現する設計図 Terraformとは、Hashicorp社が開発したオープンソースのインフラコードで、AWSの構築内容をコードで管理するサービスです。 具体的には、街を再現するための設計図のようなイメージです。仮に街で災害が発生して建物や周辺の道路が損壊してしまった時に、設計図が無いと元に戻すことはできません。そこで設計書があることで、万が一街が壊れてしまっても、構築内容を元通りに戻すことができます（ただし、ECSやRDSといった中身のデータは復元できないので注意してください）。 サーバレスなサービス導入（〜 Section 10） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例　（サービスはめ込み版） 解説 Section7までで説明した基本構成より、オフィス内で分業化をしました。これまでオフィスにあったサービスはシステム部へ、今回説明する部署を総務部へそれぞれ部署を分割しました。総務部の中で、Lambdaを用いたサーバレスなサービスの解説をしていきます。 API Gateway 概要：APIリクエストの集中管理・ルーティング制御を行うサービス 例示：受付窓口スタッフ API Gatewayは、APIリクエストの集中管理やルーティング制御を行うサービスで、どのサービスにアクセスするかを振り分ける役割を担っています。 実世界では、総務部で働いている受付窓口スタッフに該当します。ここで受け取ったお問合せ内容について、誰に仕分けてもらうかを振り分けるのと同等になります。 WAF （Web Application Firewall） 概要：攻撃と思われる通信を遮断するサービス 例示：受付窓口スタッフ （門番役） WAFは、SQLインジェクションやXSSなどの攻撃などと思われる通信を遮断するサービスで、脆弱性を狙った攻撃攻撃に防ぐ役割を持っています。 先ほど説明した受付窓口スタッフは、お問い合わせ内容の仕分けだけでなく、怪しい人が入ってきた場合はオフィスへの侵入を阻止させることで、内部処理を安全に実行することができます。 Lambda 概要：サーバレスでプログラムを実行できるサービス 例示：作業者 Lambdaは、クラウド上に直接プログラムを定義・実行するサービスです。サーバ構築も不要であり、複雑化した機能ではなく1つの機能を実行するときに役立ちます。 今回の例では、作業者（仕分け人、実行者、回答作成者、感謝文面作成＋手紙送付者）に例えることができます。このように1つの作業の橋渡し役となる大事な役割を担っています。 DynamoDB 概要：高速なNoSQLデータベース（RDSと対で使われる） 例示：問い合わせ内容の記録簿 DynamoDBは、高速なNoSQLデータベースであり、RDS（高度なMySQLデータベース）とは対で使われる。RDSは高度なSQL操作ができるが取得に時間がかかり、DynamoDBはキーバリュー型（具体例として後述）で高度なSQL操作ができないものの、高速（数ms単位）で取得可能です。 今回の例では、スーパーマーケット利用者から頂いた問い合わせ内容の記録簿として機能を果たします。問い合わせ内容は、名前（キー）と問い合わせ内容（バリュー）で紐づけることができるため、検索が容易で高速に取り出すことができます。 SQS（Simple Queue Service） 概要：メッセージを受信・保存し、順番に送信するサービス 例示：お問い合わせ書類 SQSは、メッセージを受信・保存し、順番に送信するサービスです。 今回の例では、作業者（仕分け人）が仕分けたお問い合わせ書類が保管されており、作業者（実行者）によって処理されるイメージです。 Step Functions 概要：実行対象のワークフローを自動化できるサービス 例示：現場マネージャー Step Functionsは、実行対象のワークフローを自動化できるサービスで、今回はLambda関数を順番に実行する処理を管理しています。 オフィス（総務部）の例では、作業者（回答作成）→作業者（感謝の文面作成＋送付）の流れが問題なく動いているかを、現場マネージャーが監視しています。 Bedrock 概要：高機能な基盤モデル（FM）を搭載したサーバレス生成AIサービス 例示：専門家 Bedrockとは、高機能な基盤モデル（FM）に基づいて、サーバレスな生成AIを実現するサービスです。RAGと呼ばれる最新・関連情報を優先的に検索できるデータベースを使い、その知識を基に学習をしています。 実際には、作業者の回答作成の手助けをする専門家が妥当だと思います。専門家の長年培ってきた知識情報を駆使できるため、生成AIに近い表現ができると考えられます。 SES（Simple Email Service） 概要：クラウド型のメール送信・受信サービス 例示：郵便ポスト SESとは、クラウド型のメール送信・受信サービスで、受け取った回答情報を問い合わせをしたユーザへメールを送信する役割を果たしています。 今回の例では郵便ポストに例えられて、回答作成した内容を郵便ポストに投函し、やがて利用者の手元へ届く流れとなっています。 分析・マルチアカウント対応 （〜 Section 12） AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例（サービスはめ込み版） 解説 Section10の段階から新たに赤枠の部分である、データの分析・マルチアカウント対応・監視体制の強化が加わったことで、活用かつ堅牢であるサービス構成になったのかなという感じがしています。実際にスーパーマーケット版でも、本社オフィスのシステム部が追加されて、それぞれシステム部内で部署が新たに新設されたことで対応できていることが確認できると思います。このように、データの利活用・監視を市街地でも実施していくことで、安全なまちづくりを行える意向が伺えます。 また、追加した部署の概要は下記になります。 データ管理部 ：データの分析・可視化を行う部署（Glue, Athena, QuickSight） 店舗監視部 ：店舗の設備情報・利用者の動向を監視する部署（AWS Config, CloudTrail, GuardDuty, SecurityHub） 統制部 ：店舗全体のルール作成を行う部署（AWS Organizations, ControlTower, Terraform） Glue 概要：DBに登録されているデータの収集・変換を行うサービス 例示：スーパーマーケットの売上データの収集・変換 Glueとは、DBに登録されているデータの収集・変換を行うサービスで、データの分析や可視化をしやすい状態にする役割を持っています（＝SQL実行できる状態にします）。 今回の例では、DB＝スーパーマーケットの売上データになっており、分析・可視化しやすい状態にします。 Athena 概要：変換されたデータに対して、SQL実行を行うサービス 例示：売上データ（売上高・購買率など．．．）の分析 Athenaとは、Glueによって変換されたデータに対して、SQL実行を行うことで、データ分析ができるサービスです。 今回の例では、スーパーマーケットでの売上データをデータ単位で見やすくするようにします（例：利用者Aさんは今月10万円お買い物した、利用者Bさんの今月の購買率は40%だったなど．．．）。これにより、スーパーマーケットの運営改善を行うことができます。 QuickSight 概要：変換されたデータに対して、データの可視化を行うサービス 例示：売上データ（売上高・購買率など．．．）の可視化 QuickSightとは、変換データに対して、データの可視化を実施できるサービスです。AthenaはSQL実行して指定したデータを抽出するのに対して、QuickSightはグラフを用いて可視化する役割を持っています。 今回の例では、スーパーマーケットの利用者単位での売上高・購買率の可視化などが挙げられます。 AWS Config 概要：AWSの構成情報を管理するサービス 例示：スーパーマーケット内のレジ台数・従業員数の管理 AWS Configでは、EC2やRDSなどのサービスの設定を管理するサービスで、変更履歴も検知しています。 スーパーマーケットの例では、本社オフィスの店舗監視部が店舗内のレジ台数・従業員数を管理しており、変更をした場合は、具体的な日時まで記録しておくイメージです。 CloudTrail 概要：AWS内の操作を記録・保存するサービス 例示：店舗でのレジ利用者の行動監視 CloudTrailとは、AWSの中で行われた操作を「いつ・誰がしたか」という形式で記録・保存するサービスです。 スーパーマーケットの例では、各店舗でのレジ会計時に、利用者のログを記録して監視している表現が近いかなと思います。 GuardDuty 概要：AWS上のセキュリティの脅威を継続的に検出するサービス 例示：店舗の不審者・侵入者検知 GuardDutyとは、AWS上にてセキュリティの脅威がないかを継続的に検出し続けるサービスです。 スーパーマーケットの例では、店舗内で不審者・侵入者がいないかを継続的に検知し続け、発見次第アラートを鳴らすイメージが近いかなと思います。上記で説明した「CloudWatch Alerm」と一定の基準でアラート発動という観点で同一なのですが、それぞれ検知する種類が違いがあります。 GuardDuty：「悪意あるアクセス」を検知（＝侵入者を検知） CloudWatch Alerm：「リソースの逼迫」を検知（＝混雑状況を検知） SecurityHub 概要：セキュリティ設定・監視を一元管理するサービス 例示：店舗監視部の一覧表示モニター SecurityHubとは、セキュリティ設定・監視を一元管理するサービスを表します。 本社オフィスの例では、店舗監視部が確認している設定情報の管理（AWS config）、利用者の行動監視（CloudTrail）、不審者検知（GuardDuty）を、一覧でモニターに映し出すのと同等になります。 AWS Organizations 概要：複数のアカウントを一元管理するサービス 例示：各店舗リストの保管 AWS Organizationsは、複数のアカウントを一元管理するサービスになっています。 本社オフィスの例では、各店舗（本店舗だけでなく、A店、B店、C店など）のアカウント情報を一元管理するイメージです。 AWS ControlTower 概要：複数のアカウント管理にあたって、AWSのセットアップをしてくれるサービス 例示：各店舗のマニュアルブック AWS ControlTowerは、複数のアカウント管理にあたってAWSのセットアップを行うことで、ベースラインが構築できるサービスです。 本社オフィスの例では、各店舗に対応したマニュアルブックを指します。マニュアルがあることで、スーパーマーケットの規範が成り立つので、本サービスと同等の役割を果たします。 最後に 本記事では、約40のサービスを載せていたAWSの全体像に対して、スーパーマーケットを中心とした街で例えてみました。 それぞれのサービスについての説明もしましたが、各サービスの概要・役割のみの説明で、技術的な詳細な説明はしていないので、気になるサービスは調べていただけたらと思います。 僕もこの記事執筆から、ここで紹介しきれていないサービス含め、さらなるAWSサービスへの理解を深めていけたらと思います！ 最後に、スーパーマーケット図示完成版を下記に共有いたします。

福岡Rubyist会議05 参加レポート こんにちは！Timeeでバックエンドエンジニアをしている志賀( @akitoshiga )です。 表題の通り「福岡Rubyist会議05 」に参加してきたのでそちらのレポートを書きたいと思います！ regional.rubykaigi.org 今回「Kaigi Pass」という社内制度を利用して参加しました。 「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。 productpr.timee.co.jp 会場の様子 当日は福岡県福岡市博多区にある「リファレンス駅東ビル」というところで行われました。 会場いっぱいに来場者が集まりとても賑わっていました。 また、会場には福岡県八女市の名物である八女茶が提供されていました。 自分もいただいたのですがとても美味しかったです。 セッション 特に自分の関心が高かったセッションを3つほど紹介したいと思います。 SQLQL とは何だったのか 発表者 : yancya( @yancya )さん www.slideshare.net yancyaさんが取り組まれているSQLQLについての概要と、技術の変遷に伴ったアップデートのお話でした。 SQLQLとはWebクライアントからSQLクエリを送信して、その実行結果をJSONで返すというコンセプトです。 GraphQLのSQL版と考えるとイメージが掴みやすいと思います。 SQLQLに関しては以下で詳しく解説されています。 SQLQL #Rails - Qiita SQLQL とは！？ | PDF なお、ここではRDBMSにPostgresを使用することを前提としています。 SQLQLはクライアントが任意でSQLを送信できるので、これを安全に使えるようにするためにさまざまな工夫が施されていました。 WITH句によるCTEを使って取得対象のDBをラップすることでアクセスできる属性を絞り、秘匿すべきデータへのアクセスを制限しています。 INSERT, UPDATE, DELETEといった副作用を伴う操作に関しては自由に実行できないようにSELECTのみの権限しか実行ユーザーには与えず、定義した書き込み権限のあるストアドプロシージャでしか副作用のある操作を実行できないような仕組みを取られていました。 また、悪意のあるクエリの対策としてpg_queryによってクエリをパースしてAST（抽象構文木）をチェックしていました。 課題も存在していて、再帰処理にはうまく対応できないそうです。 SQL ServerやMySQLは再帰処理の深さを設定できるのですが、Postgresだと存在していないため代わりにタイムアウトのみで設定しているそうです。 クライアントでクエリをフェッチすることが可能になるので、これを用いたときにAPI開発コストの削減に繋がるのは良さそうだなと思いました。 ビジネスロジックがストアドプロシージャに集中してしまわないかなというのと、サーバー側ではクエリを効率化できないのでデータ量が多かったりリレーションの複雑なテーブルからデータを取得する場合はクライアント側で工夫が必要だなと感じました。 SQLをそのままパラメーターにしてWeb経由でクエリを投げるアイデアと、安全性を担保するためのさまざまな試みに技術者のロマンを感じました。 再帰処理に関してはPostgreSQLに存在するCYCLE句を使えば安全に扱えそうなのですが、そうすると特定のRDBMSに依存してしまうのと、クライアントとクエリの決め打ちをしなければならずコンセプトと乖離しそうな気がするので悩みどころだなと感じました。 今回はこのSQLQLのアップデートとしてWAL監視のアイデアを取り込んだデモアプリを披露されていました。 WAL（先行書き込みログ）とはデータベースに変更を行う前に操作内容を記録するログのことであり、このWALを監視することでリアルタイムなデータストリームの観測が可能で、このアイデアをSQLQLに応用されていました。 WAL監視については自分は初見だったのですが、CDC（Change Data Capture）の実装に利用されたりしているそうです。e.g. Debezium Server このほかにもSQL標準の変遷やLive QueryなどSQLQLを起点としてDB 、データ基盤についての幅広いお話を伺いました。 Live Queryで話に上がっていたKafka Streamsについては内部動作と構造に興味が湧いたので後日その深掘りをしてみました。 また、WAL監視については今後複数コンポーネント間でリアルタイムにデータ更新を検知したいときなどにこのアイデアが役立ちそうだなと思いました。 型を書かないRuby開発への挑戦 発表者 : shia( @riseshia )さん speakerdeck.com 自作GemのTypeGuessrのお話。 TypeGuessrは「型情報を開発者が追加せずに型情報を得る」ことをコンセプトに開発されたGemで、Ruby LSPのアドオンという形で使用します。 github.com Rubyに型情報をもたらすツールはいろいろありますが、SteepやSorbetといったような型定義を行い正確な型情報を得るものとは明確に棲み分ける形で開発されています。 Hash/Arrayに対してStructural Typing（構造的部分型）をサポートしつつも複雑な型推論が走りそうな場合はあえてuntypedにして計算量をコントロールしています。 特徴として、Duck Typingに基づくヒューリスティックな推論を用いて型情報を取得しており、クラスに定義されたメソッドをそのレシーバーから辿ることによってこれを実現しています。 この方法でも行数が10万行以上のRailsプロジェクトであれば平均10%〜20%で型情報を得られるそうです。 Duck Typingを利用して振る舞いから型を推論する部分はRubyらしさを感じるとともにユニークで興味深いなと思いました。 まだできたばかりでパフォーマンスには向上の余地があるそうで、このアプローチでどのようにこれらを解決していくのか動向を追ってみたいなと思いました。 少し話は逸れますが、型検査ツールのパフォーマンス改善という話でふと去年の関西Ruby会議で聞いたpockeさんのこのキーノートを思い出しました。 speakerdeck.com Steepのメモリ削減のために自作のプロファイラで観測してプロセス間通信のレベルまで踏み込んで改善に取り組んだ過程がとても面白かったので、よかったらこちらもチェックしてみてください。 Ecosystem on parse.y 発表 : S.H.さん S.H.さんが開発されているparse.yを利用したGemであるkanayagoとigata、そしてこれらを組み合わせたエコシステムのお話 parse.yとはRubyの文法定義ファイルのことで、昨今のRubyist界隈を取り巻くパーサームーブメントを語る上で欠かせないものです。 parse.yはRubyコミッターのydahさんの以下のスライドがparse.y周辺の情報やパーサー自体についても丁寧に解説されていて理解しやすいです たのしいparse.y - Speaker Deck S.Hさんはこのparse.yを利用して、パースしたAST（抽象構文木）ノードをRubyクラスとして扱うことができるkanayagoを開発されました。 github.com ASTをRubyオブジェクトにすることで従来よりももっと手軽にASTを扱えるようになり、パターンマッチングにも対応可能になっています。 これによってコード解析・構文チェックなどといったRubyの文法のASTに関する操作がとても直感的・簡単に行えるようになっています。 またS.Hさんはこのkanayagoをベースとしてigataとkanayago-lspを開発されました。 github.com igataはkanayagoが生成するRubyクラス名、メソッド名、引数の情報などを抽出してMinitestやRSpecに対応したテストファイルを自動作成します。 これに加えてLLMと組み合わせて、テストの中身まで自動補完させる運用も想定されています。 kanayago-lspはkanayagoを用いてVSCodeやVimなどで利用でき、Rubyの新しいパーサーであるPrismでは検知できないものも検知できるそうです。 S.Hさんはこのparse.y、これを利用したkanayagoを利用したエコシステムの構築を目指しており今後はLinterの開発を目指しているそうです。 S.HさんのASTに使われる各ノードを体系立った独自のRubyクラス群にラップするというアイデアがとても素晴らしいなと思いました。 parse.yから生成できるノードは100種類以上あるのでかなり根気がいる作業だと思いましたが、ここは生成AIをうまく活用されたそうです。 Ruby3.4からデフォルトパーサーがparse.yから生成されるパーサーからPrismに置き換わりましたがparse.yの根強い人気というか盛り上がりを感じました。 先ほど紹介したTypeGuessrもそうなのですが、何かを作るにあたりよりRubyらしさを追求するアプローチをみなさんされていて、このマインドはRubyistに通じるものなのかなと感じていました。 これらは開発のお手伝いをしてくれる方を絶賛募集中とのことです。自分もとても興味があるので機会があればパッチを投げたいなと思いました。 そのためにkanayago自体も積極的に使ってみたいと思います。 これらの他にもこの日のセッションはPicoRuby、VM、Deep Researchなど、とてもバラエティに富んでいて非常に面白かったです。 まとめ 福岡Rubyist会議に参加したのは初めてだったのですが、自分は人との距離が近い地域Ruby会議が好きなので今回行くことができて良かったなと思いました。 セッション終了後にも以前からオンラインでお世話になっていたコミュニティの方や、現地コミュニティの方々とも交流できたのも非常に嬉しかったです。 ぜひまた次回も参加したいと思います！