React+Go+MysqlでSPAのTodoWebアプリをAWS EKSにデプロイしてTerrraformでIac化までやった_序章
はじめに
はじめまして。
3年半ほどNW(大体オンプレ)を中心にインフラエンジニアをしてるものです。
この度初めて技術ブログなるものを執筆していきます。
たまにAWSやAzureのネットワーク絡みの構築とかはあるのですが、どうしてもサービス提供に付随したコアな開発に関わる部分は触れる機会がないなーと思い、
そこらへんの知識を身につけるために、この度React+Go+MysqlでSPA型のTodoWebアプリを自作してAWS EKSにデプロイしてTerrraformでIac化するとこまでやろうと着手してました。
(着工期間およそ5ヶ月くらい)
せっかくならフロントエンドもバックエンドもインフラも網羅的に理解しようと企み
(力の入れ具合の濃淡はあれど)いわゆるフルスタック的な感じに取り組みました。
しかし、「こんなすげーもん作ったぞ!」というつもりは毛頭なく、むしろ「この実装イケてなくね?」という反省の念が多くあるため、
今後に活かすため、このブログを通じて振り返りを実施し、更によいアーキテクチャーをつくれるように改善の記録をこれから記事にしていきたいと思ってます。
注意書き
-
この記事は、各種公式ドキュメントや参考記事から得た知見、と自身の仮説に基づいた検証結果を下に執筆してますが、内容の正確性や完全性を保証するものではありません。
-
AWSを一部用いており、簡単な実装手順の紹介がありますが、内容によっては無料枠に収まらず課金が発生するものもあります。
そのため、もし参考にして実施したい場合は、料金ダッシュボードをこまめに確認し、予期せぬ請求が発生しないよう注意してください。
想定外の請求が発生してしまっても、責任は負いかねますので、ご了承ください。
作ったもののご紹介
詳しくは以下のgithubのreadmeをご覧ください。
今回は序章として、作成物の簡単な概要について触れていきます。
Todoアプリの概要
せっかく作るなら、よくある入門本にあるようなTodoアプリだと
つまらないので、あくまでコンセプトありきで「こういうの使いたいな」と思うアプリを作ろうと思い
日頃世話になってるタスク効率化メソッドの一つである、「アイビー・リーメソッド」型のアプリにしようと思いました。
アイビー・リーメソッドとは?
端的に言えば、以下のルールを定めたTodoリストであります。
- 今日やるべきタスクは6つまで登録できるが、それ以上は登録できない。
- 6つあるうちの1つ目から順に消化するがそれが終わるまで2つ目のタスクとそれ以外のタスク(微細なタスクは除く)は実施できない。
- 1日の完了時点で6つのタスクが終わろうと終わるまいとすべてリセットされ、
また翌日に6つのタスクを登録し1.のルールに戻る
これは、20世紀前半、アメリカ最大の鉄銅会社であったベツレヘム・スチール・コーポレーションの社長チャールズ・M・シュワブ氏が、会社の経営の効率化のために、コンサルタントのアイビー・リー氏を雇いました。
そこで、リー氏が考案したメソッドが、アイビー・リー・メソッドであります。
シュワブ氏は、このメソッドに対して
「これまで受け入れたアドバイスの中で最も有益だった」と言い、
リーに対し、25,000ドル(現在の価値でおよそ4400万円)をリーに支払ったという
ある種伝説のTodoリストです。
参考①:決断疲れ_wikipedia
参考②:アイビー・リーメソッド_studyhacker
アプリの内容紹介
以下のような感じでアプリを作成しました。
操作デモ動画(画質荒っ)
メイン画面
タスク作成
タスク編集
6つの今日やるタスクが上限に達した
このアプリの特徴は以下のルールに則っていること。これにより決断疲れの消耗を抑えることを期待してます。
- 今日やるべきTodoは6つまで登録できるが、それ以上は登録できない。
- 6つのタスク以外のそれ以外のタスクは実施できない。(6つのタスク欄に昇格をすれば可能)
- 1日の完了時点で6つのタスクが終わろうと終わるまいとすべてリセットされ、
また翌日に6つのタスクを登録し1.のルールに戻る
また、いわゆるSPA(Single Page Application)で作成してますから、ページ遷移速度を向上させユーザー体験を損なわないようになってるかと思ってます。
基本的には画面でポチポチ表示したり、タスクを作成したり移動したりする機能はReactにてAPIリクエストを行い、Goで作成したAPIサーバーが中継役となり、
パスの内容に従ってデータベース(RDS for Mysql)にデータを書き込んだり取得したりします。
インフラ部分の全体構成
インフラ全体は以下のような感じになってます。
- 先ほどお話ししたReactなりGoなりのコードはAWS EKSクラスター内にて作成されたマネージドノード(EC2)上で動くpodにて動作しています。
- データベースはAWS RDS for MySQLを使用しており、GoのPodからクエリを実施して、そこからデータを取得したりするようにしています。
- 外部からのアクセスはRoute53による名前解決+ACMで発行された証明書でHTTPSアクセスを、ALB(EKSで作成したAWS Load Balancer ControllerのIngressリソースによって管理されてるやつ)に対して渡されてそれが負荷分散されてEKSに対して通信が行われてます。
- EKS内で外部から受け取った通信はリバースプロキシ役のnginxとreactアプリが搭載されたフpodに渡され、APIリクエスト時は背後のGoのpodに対して適宜通信を行っています。
- データベースのマイグレーションはgolangのmigrateを使用してます。これもEKS上のjobポッドとして作成し、RDSのマイグレーションはこいつを実行して行うようにしてます。
- データベース認証情報はAWS Secrets ManagerとKubernetesのSecretを連携させる実装(AWS Secrets Manager and Config Provider for Secret Store CSI Driver ...通称ASCP)を使用して
そこからデータベース認証情報を取得しています。 - Iacとしてterraformを用いて、stateを管理しており、tfstateファイルはリモートバックエンド機能によりAWS S3に保存されており排他制御のためにdynamodbを併用しています。
企画について
とまあ、それなりにモダンな技術をたくさん使ったアーキテクチャになりますので、この1つの記事だけでは、隅々まで到底お伝えできないなと思ってます。
なので、はじめにでもふれましたが、振り返りと改善の記録をこれから記事にしていく企画として良きも悪きも吐き出していきたいと思います。
どういう情報を誰あてで届けたいのか。
おそらく、この記事を読んでいただいている読者の中には、IT業界に参画を目指している人やITを使って今後更に社会で活躍していきたい!ていう意欲のある方が多くいるのかなと思います。
ただ、ネット上には色々と有益なハンズオンだったりHowtoだったりが落ちてるとは思いますが、
どうしても「このハンズオンを習得した暁にどうやって仕事に活かせるのか」「そもそもなんでこれがベストプラクティスなのか」「逆に悪い実装がなにでどういう問題に対して使うべきなのか」というのが気になってしまうと思います。
技術を点として理解するだけではなく、線にして面にして生きた物として会得するためには、どういう課題があってなにを解決しようとして実装したのかとか、ある技術とある技術がどう相互に作用し関連し依存しているのか、それがどういったレイヤーで動いており類似機能との優位点はなにかといった情報を知り、ときに練習を重ね身につけていくこと重要であると認識してます。
ただ、そういった情報はあまりネット上では落ちておらず、どんなに優れたコンテンツであれど、それが点で終わってしまいすぐ忘れてしまう、ということはたくさんあるのかなと思ってます。
今後の記事の作成方針
なので、今あるアーキテクチャをベースとして各記事の内容としては以下の3つの視点を各記事で取り扱って行きます。
- このアーキテクチャを作った経緯や、技術選定のきっかけ、具体的にどういう実装を行ったかを記す
- 作っては見たものの、だめな部分や課題点だったり、今後どのように変えて行く方針かを記す
- 2.の発案やベストプラクティスを鑑みて変えていくべきと思った、箇所を実際に変えてリファクタリングを試みる
特に2.の視点は重要かなと思っていて、実のところ作っていながら
- 「運用を考えた実装になってんの?」
- 「継続的インテグレーションできなくね?」
- 「これでコストは最適化されてるの?」
- 「アプリケーションのユーザー認証なくね?」
- 「DRYって知ってる?」
等々現場で実際に稼働してるアプリケーションとかと比べると多分にツッコミどころがあったりしてます。
せっかく手掛けるなら、実際の現場で稼働しているシステムと何ら変わりないようなレベルのものを作っていきたいと思ってますので、そういう意味で大いに改善のしようがあるわけですね。
もちろん、Golang、react、docker,kubernetes,eks,terraformの個別ノウハウや技術についてもそれはそれで触れようとは思いますが、
「まだまだこのアーキテクチャは伸びしろがある」ということで、成長記録的な側面としてもアウトプットしていきたいです。
終わりに
色々書き連ねましたが、ここまでが序章であり、次回から振り返りをしつつ改善策をどう実施していくかみたいな考察をしながら記事を書き留めて行こうと思います。(ハンズオンとかを期待してくださってお読みいただいた方、すみません。次回から本格的に進めて行きます)
多分ですが、初回は「terraformでAWS環境を実装してこう!」とか「dockerでアプリケーション開発基盤作ろう!」あたりの比較的イージーな話を展開するような気がします。
また、本企画とは何ら関係のない、その他の記事も書いていきます。(NWの話とかAWS資格の話とかetc...)
ぜひ、コメントや当方のXでもご指摘やご声援などいただければ、もっともっとよりよいものにしていけると思います。
ということでゆるく長く続けて行きますのでよろしくお願いします。
最後までお読みいただきありがとうございました。
Discussion