【ITニュース解説】Built a Full-Stack GitHub-Integrated Notion Productivity Tool

GitDoneは、学生開発者が直面する複数の締め切り管理の困難を解消するために生まれた、フルスタックの生産性向上ツールだ。GitHubと連携し、リポジトリ内の目標、例えばプロジェクトの出荷、バグ修正、バージョン更新などに対して、リアルタイムの締め切りカウントダウンを表示する。特定のキーワードを含むコミットがリポジトリにプッシュされると、カウントダウンは自動的に完了する仕組みである。このカウントダウンはNotionのような他のツールに埋め込むこともでき、開発者のワークフローを一箇所に集約できる。GitDoneは、ユーザーが操作する画面（フロントエンド）から、データの処理を行う裏側（バックエンド）まで、すべての機能を備えたフルスタックのアプリケーションとして、クラウド環境での運用を前提に設計されている。

プロジェクトはまず、ユーザーインターフェースにあたるフロントエンドの簡単なプロトタイプから始まった。標準的なHTMLとCSSで最初のバージョンが作成されたが、より現代的で使いやすい体験を提供するため、Amazon KiroというAIパートナーの活用が決定された。Kiroはプロジェクトの要件をブレインストーミングし、大まかなシステムの構造（アーキテクチャ）を検討し、開発タスクを管理しやすい小さな単位に分解するのに役立った。特にフロントエンド開発においては、AIエージェントのサポートが非常に大きかった。例えば、様々なデバイスの画面サイズに対応するレスポンシブデザインを実現するため、CSSの記述を整理し直すことや、ユーザーの好みに合わせて画面の表示を明るいモードと暗いモードで切り替えるJavaScriptの機能を実装することができた。さらに、各目標に対して固有の埋め込みリンクを動的に生成し、表示するクライアントサイドのロジックもAIの助けを借りて作成された。

ローカル環境で動くプロトタイプから、多くのユーザーに利用される本番レベルのアプリケーションへと進化させるには、信頼性、拡張性、そしてセキュリティが不可欠となる。そこで、クラウド環境へのデプロイが計画され、Amazon Web Services（AWS）が選ばれた。アプリケーションは、機能ごとに役割を分離する3層アーキテクチャで設計された。

まず、ユーザーからの要求を受け取り、データの処理やフロントエンドの画面生成を行う「バックエンド層」がある。これはPython言語で書かれたFlaskフレームワークのアプリケーションで構築され、異なるシステム間でデータをやり取りするための取り決めであるREST APIを提供し、ウェブページを動的に生成する役割を担う。

次に、アプリケーションが扱うすべてのデータを永続的に保存し、安全に管理する「データ層」が設置された。ここではAWS RDS（リレーショナルデータベースサービス）のPostgreSQLデータベースが採用された。RDSはデータベースの管理（バックアップ、パッチ適用など）をAWSに任せられるマネージドサービスであり、データの安全性と耐久性を高める。

そして、バックエンドアプリケーションを実行するサーバー資源を管理する「コンピュート層」にはAWS Elastic Beanstalkが利用された。Elastic Beanstalkは、背後にあるEC2という仮想サーバー群のインフラストラクチャを自動的に管理し、アプリケーションのデプロイ（配置）、アクセス負荷に応じたサーバーの増減（ロードバランシング）、サーバーが正常に稼働しているかの監視（ヘルスモニタリング）などを自動で行う。

さらに、ユーザーに高速で安全なウェブ体験を提供する「エッジ層」としてAWS CloudFrontが導入された。CloudFrontはコンテンツデリバリーネットワーク（CDN）の一種で、ウェブサイトの画像やJavaScriptファイルなどの静的なコンテンツを、ユーザーに地理的に近いサーバーにキャッシュすることで、表示速度を向上させる。また、カスタムドメイン（gitdone.online）の管理や、ウェブサイトの通信を暗号化するSSL/TLS証明書の終端処理も行い、セキュリティ面も強化されている。

このように、各コンポーネントが役割を分担する強固なシステムが机上では設計されたが、実際にこれらすべてを連携させて動かすことは大きな挑戦だった。

初めて複数のサービスを組み合わせたアプリケーションをクラウドにデプロイする際、多くの問題に直面した。その解決の過程は、実際のクラウドエンジニアリングにおける貴重な学びとなった。

最初の大きな問題は、ファイルベースのSQLiteデータベースを使っていたことだった。開発環境では問題なく動作したが、クラウドサーバーに再デプロイするたびに、それまで保存されていたアプリケーションのデータがすべて消滅してしまうことに気づいた。これはクラウドサーバーが、アプリケーションを再デプロイしたり、何らかの理由で新しいサーバーに切り替わったりする際に、以前のサーバー上のローカルなファイルは保持されないという一時的な性質を持っているためである。この経験から、データの永続性を確保するには、別の方法が必要だと痛感した。その結果、データ層をAWS RDSへと移行し、この問題は解決された。

RDSへの移行後も、アプリケーションは起動しなかった。Elastic Beanstalkのログを詳細に確認したところ、二つの原因が判明した。一つは、Pythonアプリケーションのメインファイルであるapplication.pyのファイル構造と、Elastic Beanstalkがアプリケーションを起動するために設定するWSGIPathという設定値が合致していなかったことによるModuleNotFoundError（必要なモジュールが見つからないエラー）だった。もう一つは、データベース接続情報を含むDATABASE_URLという環境変数に単純なタイプミスがあり、アプリケーションがデータベースに接続しようとする段階でSQLAlchemy URL Parse Error（データベースライブラリによるURL解析エラー）が発生し、起動に失敗していたことだ。これらを修正することで、アプリケーションは正常に起動するようになった。

アプリケーションが起動するようになった後も、次の問題が発生した。ウェブサイトにアクセスすると「504 Gateway Timeout」エラーが表示され、アプリケーションがデータベースに接続できない状態だった。これはAWSのネットワーク設定、特に「セキュリティグループ」と呼ばれる仮想的なファイアウォールが適切に設定されていなかったためだった。セキュリティグループは、どの通信を許可し、どの通信をブロックするかを制御するもので、アプリケーションの各部分が互いに通信できるように、慎重な設定が必要だった。具体的には、CloudFrontがElastic Beanstalkと通信できるようにするルール、Elastic BeanstalkがRDSデータベースと通信できるようにするルールを追加した。また、開発者が自分のローカルマシンからデータベースに接続して初期設定を行うための一時的なルールも設定し、これによりデータベースへの接続問題を解決した。

さらに困難な状況として、ある時、設定更新が失敗したことでElastic Beanstalk環境が「UPDATE_ROLLBACK_FAILED」という、ロールバック（以前の状態に戻す処理）も失敗した状態に陥り、コンソールからの操作ができなくなったことがあった。この時はAWS CloudFormationコンソールを直接操作する必要があった。CloudFormationはAWSリソースをコードで管理するためのサービスであり、ここから手動で失敗したリソースをスキップし、強制的にロールバックを完了させることで、この「スタックが動かなくなった」環境を無事復旧させることができた。

これらの複雑な問題を一つ一つ解決した後、アプリケーションのデプロイワークフロー全体の自動化に着手した。AWS CodePipelineを利用して継続的インテグレーション（CI）と継続的デリバリー（CD）のパイプラインを構築した。これにより、GitHubのメインブランチに新しいコードがプッシュされるたびに、自動的にビルド、テスト、そしてElastic Beanstalkへのデプロイが実行されるようになった。この自動化によって、これまで手動で行っていた5つのステップのデプロイ作業が不要となり、ヒューマンエラーのリスクを大幅に削減するとともに、真の継続的デリバリーが実現された。

長い開発とデバッグの道のりを経て、GitDoneは現在、専門的なクラウドアーキテクチャ上で安定して動作する、フル機能かつ拡張性の高いアプリケーションとなっている。このプロジェクトは完全にオープンソースとして公開されており、究極的にはコミュニティが貢献し、今後の機能追加や統合、例えば締め切り前のメール通知機能や、GitLabのような他のGitプロバイダーへの対応などを通じて、その未来を形作っていくことが期待されている。