アプリ開発で、大事なことを身につけるために Herokuが教えてくれる２つの要素

昨日、[Heroku Meetup #22 "Heroku Masamune"](https://note.mu/hashtag/22) が開催されました。EC-CubeとDocker話をメインコンテンツに、その他、5つのLTが行われました。私も普段どおりの宣伝だけに近いLTを開催しましたが、それはまた別のお話。

そのLTの中で、とても良いコンテンツがありましたので、紹介します。[@shokai](https://scrapbox.io/shokai) さんの 「[大切なことはだいたいHerokuで学んだ](https://scrapbox.io/shokai/%E5%A4%A7%E5%88%87%E3%81%AA%E3%81%93%E3%81%A8%E3%81%AF%E3%81%A0%E3%81%84%E3%81%9F%E3%81%84Heroku%E3%81%A7%E5%AD%A6%E3%82%93%E3%81%A0)」です。

# ところで Heroku とは

`Heroku` は、Platform as a Services (PaaS)です。Ruby、Java、Javascript、PHPなどのメジャーなプログラミング言語から、Go言語、Scala などまで幅広く8種類のプログラミング言語の動くWebアプリケーションプラットフォームです。いわゆる PaaS の中では歴史は古く、2007年よりサービスが開始されています。Heroku プラットフォームの特長は、Heroku Founder の "[Adam Wiggins](http://about.adamwiggins.com/)" が執筆した、アプリケーション開発の方法論 "[The Twelve Factor App](https://12factor.net/ja/)" がベースとなっていることです。

Heroku でアプリケーション開発を行った場合、"The Twelve Factor App" に従った Webアプリケーションを開発することに適している、と言いますか、それを矯正させられます。例えば、Gitと密接なソースコード管理、依存関係の明確化、個別の設定は環境変数、ポートバインディングされたサービスの公開、シェアドナッシング(ステートレス)によるプロセスのスケールアウト、開発・本番環境の一致...など、Heroku を利用されたことのある人には、その強制力に驚かされた人もいるでしょう。ステートレスを強制し、廃棄容易性を追求してセキュリティを高めた結果、ローカルにファイルを永続的に配置することはできず、データベースやオブジェクトストレージへの保存が必要不可欠です。

レガシーなアプリケーション開発に携わったことのある方にとっては、制限・制約の多いプラットフォームと思われるかもしれません。ですが、モダンなWebアプリケーション開発として、とても優れています。

ようやくの本編ですが、「[大切なことはだいたいHerokuで学んだ](https://scrapbox.io/shokai/%E5%A4%A7%E5%88%87%E3%81%AA%E3%81%93%E3%81%A8%E3%81%AF%E3%81%A0%E3%81%84%E3%81%9F%E3%81%84Heroku%E3%81%A7%E5%AD%A6%E3%82%93%E3%81%A0)」では、この強制力によって、次の２つの点でよかったと述べられています。

1. 悪い設計をさせてくれない
2. 運用しやすい設計になる

# 1. 悪い設計をさせてくれない 

`Heroku` は、"[The Twelve Factor App](https://12factor.net/ja/)" を強制してくるプラットフォームのため、この制限から外れると、それは「エラー」として表面化してきます。そもそもデプロイできないようなケースもあるでしょう。また、24時間+αの時間が経過して Heroku Dyno (アプリケーションの稼働するコンテナのこと)が自動リスタートしたあと、アプリケーションが正常に動作しないケースも発生するかもしれません。

「なんで、24時間でリスタートするんだよ」とお思いかもしれません。しかし、このお陰で Security Patch が迅速に適用され、安全な環境をすばやく提供しています。そして、障害テストを常に実施していると見れば、この仕掛けがあるからと言って、なんの問題もないはずです。対障害性の高いアプリケーションとして設計されていれば、不意のアプリケーションの停止や再起動が発生しても、サービスに影響は与えないでしょう。可用性の高いアプリケーションとして設計されていれば、そもそも問題にもなりませんよね。

要するに、「良い設計を強制する」仕組みを提供するプラットフォームでもあるということです。

このように「悪い設計をさせてくれない」アプリケーションが開発できれば、多くのプログラマーが良い設計のアプリケーションを開発することができるようになるでしょう。また、可搬性高く、どこのプラットフォームでも動かすことができるというメリットも生まれます。"[The Twelve Factor App](https://12factor.net/ja/)"で組まれたアプリケーションであれば、開発時の共通言語にもなります。開発者同士での対話でも、良し悪しや目標を共通化しやすいという価値が生まれます。

# 2. 運用しやすい設計になる

良い設計で構成されていれば、必然的に「運用しやすい」デザインともなるでしょう。

障害が発生しても、オートヒーリングさせやすく復旧しやすい。アクセス過多や、処理量の増加により、リソースが足りなくなれば、瞬時にスケールアウトして対応できる。ログは全て決められたイベントストリームから排出されてくるならば、それだけを追っておけばすべてのログを確認できる。ソースコードベースなので、いつでもデプロイできるし、すぐにロールバックもできる。

「[大切なことはだいたいHerokuで学んだ](https://scrapbox.io/shokai/%E5%A4%A7%E5%88%87%E3%81%AA%E3%81%93%E3%81%A8%E3%81%AF%E3%81%A0%E3%81%84%E3%81%9F%E3%81%84Heroku%E3%81%A7%E5%AD%A6%E3%82%93%E3%81%A0)」でも述べられているように、良いデザインで設計されたアプリケーションは、Heroku が全てマネージしてくれるため、運用専門のメンバーを準備せずとも運用可能です。

継続的な開発のために Heroku Pipelines と Heroku CI を組み合わせた CI/CD 環境を準備しておけば、開発者は Github へのコードコミットとプルリクエストだけできれば、Heroku へ自動的にアプリケーションがデプロイ&リリースされます。

# まとめ


Heroku でアプリケーションを開発すると、「良い設計」を強制され、「可搬性の高い」アプリケーションを開発することができるようになります。

かと言って、さぁ他のプラットフォームでも動かそうかと言うと、ベンダーロックインされてもいないのに、「Herokuで動かそう」という気持ちになります。これは、Heroku 自体のデザインを、開発者が、開発者のために行い、開発者が使いやすいように作っているからと言えるでしょう。開発者こそ、Heroku プラットフォームに共感を得ることはできるのではないでしょうか。

最後に、もう一つ文章を引用して終わりにします。

> (Herokuは)「根底に[**技術的正しさ、公正さ**]を感じるので、信頼できる」