「Hasura GraphQL Engine」について
小田川拓利氏：その中でHasuraについて説明していきます。
Digital Billderでは「Hasura GraphQL Engine」を導入しています。これはそもそもどういった技術かというと、データベースのスキーマ、つまりテーブル構造から、自動でGraphQLのエンドポイントを作成するようなサービスです。
（スライドを示して）ちょっと字が小さくて見えづらかったら申し訳ないんですが、データベースのスキーマを定義するだけで、request、where、requesterIdが$userIdに等しくて、createdAtの降順で並べて、20件まで取得するみたいなGraphQLのクエリを叩けるようになっています。何もコードを書かずに、ほとんどそのサーバーが立ってしまうといったようなものになっています。
これによって、そもそもコードを書かなくても開発できます。さらに、各APIについての権限設定や、Remote Schemas機能を用いて、各マイクロサービス、Hasuraの後ろ側にバックエンドのサーバーを立てるのですが、そのサービスとも結合して、フロント側のGraphQLをHasuraに送れば、その後ろのサービスまで取れるといったようなことまで実現可能となっています。
これによって開発者間でのGraphQLのスキーマ定義の共通化、簡単な権限管理とローコードによる高速開発というところで、開発のスピードを加速してやれるようになっていて、Hasuraを導入して良かったなといったところです。
「Hasura GraphQL Engine」を含めた構成図
（スライドを示して）先ほど同じような図で違う観点から見ています。技術的にはこういったところを使っていて。フロントエンドからHasuraで叩いて、その後ろにマイクロサービスで発注用のサーバーと経費精算用のサーバーが立っていて、その間をgRPCで通信しています。認証基盤としては「Lambda」「Cognito」を使っています。
全体としては、TypeScript、Turborepoを用いています。TurborepoはNode.jsのnpmパッケージのMonorepoを使う上で非常に便利なツールです。ビルドやテストなどのキャッシュをけっこう効率的に行ってくれる、Vercelが開発しているツールです。
運用面のところでどういったことをやっているか
運用面のところでどういったことをやっているかというと、CognitoとHasuraを連携しています。結局サーバーが立つといっても、やはりユーザーさんに取ってほしくないデータは当然あります。
会社によってその権限をかなり厳密に設定しなければいけないというところで、どういった手法を取っているかというと、弊社の認証・認可基盤としてAWSのCognitoを用いています。その手前にLambdaを用いて、Lambdaを通してカスタムクレームをJWTに付与しています。
これによってHasuraの情報、電子メールやユーザーのロールをカスタムフレームをJWTに含めて、その認証情報をまたHasuraに送って、そこで認可処理を行う。そういったことをやって認証・認可機構を実現しています。
「Amazon Aurora」と「WAF」を活用したデプロイ
最終章になります。これをどのようにAWSにデプロイするかです。
ここのポイントとしては、いかに運用の大変さを下げられるところは下げるというところにはなるかなと思います。マイクロサービスで複雑化するインフラの運用コストを下げるというところで、マネージドサービス、IaCを大きく2つに分けて紹介していきたいなと思っています。
1つは「Amazon Aurora」。フルマネージドなデータベースサービスですね。あとは「WAF」（AWS WAF）。セキュリティ関係のWAFを使っています。
まずAmazon Auroraです。有名なサービスかと思いますが、高性能で高速なスループットを持っていて、「MySQL」の5倍、「PostgreSQL」の3倍の処理を実現できます。あとはリードレプリカを増やせたり、高速化と高可用性を実現して、使用量に応じたオートスケーリングや、インフラの管理コストの低減ができることなどが利点です。
AWSのWAFです。こちらは自動でのセキュリティ対策というところで、マネージドルールで脆弱性を利用した攻撃をブロックします。過去にはLog4jの脆弱性を利用したような攻撃を特定してブロックするといったような、けっこう器用なブロックができたり。DDoS攻撃とかがあった時に緩和ができるというところでも、運用面で自動でマネージドなサービスを使うことで楽ができています。
あとはKubernetesのマネージドサービスというところで、「EKS」を利用していて、このあたりはEKSに乗っかって、Kubernetes Masterの管理はお任せしています。既存のAWSサービス、「IAM」「KMS」などの統合もやっています。
「Flux CD」を導入したKubernetesのリソース管理
後半はそれを使ったIaCについて、弊社ではどういったことをやっているかというところで、ちょうど最近「Flux CD」を導入し、GitOpsによるKubernetesのリソース管理をしようとするところを進めています。
まずGit管理で整合性を取っているといったところです。「GitHub」のコードを見れば今のインフラがどういう状態なのかがわかるのはKubernetesの基本的なところではありますが、GitHub ActionsではなくFlux CDからコードを取ってきて、その変更を感知してデプロイするので、セキュリティが担保できます。
GitHub Actions上になにかインフラを触るような権限を持たせずに、インフラ側から取ってくるような仕組みになっているので、よりセキュリティが確保できる仕組みですね。flux.yamlとしてYAMLを生成するようなイメージです。
流れとして、最初は請求書のサービス、「invoice」というレポジトリ名なので、invoiceと呼びます。そのinvoice GitHubレポジトリのコードが変更されるたびにGitHub Actionsが走って、コンテナがビルドされて「ECR」上にプッシュされます。
次にそのECR上のDockerのイメージが更新、変更されたのを検知して、image-reflectorに通知が行きます。
その後、通知されたimage-automationがマニフェストを変更するようなPR、レポジトリを出します。
それがマージされた瞬間にFlux CDがデプロイメントを更新して、EKS上のサービスが更新されるような仕組みとなっています。
マニフェストベースで、リスクを低減しながら運用できている
このように、マニフェストでさまざま管理できるというところで、デプロイ状況はコードベースで管理できているので、非常にシンプルな仕組みで運用できているかなと思います。
また、先ほどの繰り返しにはなりますが、GitHub Actionsに強い権限を持たせる必要がなく、コンテナ操作をFlux CDのプル型で行っているので、より運用上のリスクも低減できているかなと思います。
環境間の移行も簡単で、Kustomizationなどを組み合わせれば環境変数などをすぐに変更することが可能なので、そのあたりも非常に役に立っています。
今回は触れませんでしたが、「Terraform」を用いて、その他のインフラや権限周りのIAMロールなどを管理しています。これらを組み合わせることで、非常に複雑なマイクロサービスのアーキテクチャであっても、IaCを用いてうまく運用できているかなといったところです。
以上のように、マイクロサービスのアーキテクチャとHasuraを導入して爆速開発しつつ、そこの後ろにある複雑なインフラに対しては、マネージドサービスやEKS、Fluxを用いて運用コストを低減しています。
こちらで本日の発表は終わります。採用強化中なので、「Wantedly」などでお問い合わせください。以上です。
