本記事は株式会社 Works Human Intelligence の アドベントカレンダー の 10 日目の記事となります。
そんな節目の今日は、アーキテクチャ、特にAWSのアーキテクチャを考えた際にずーっとモヤモヤ思っていたことに対するアンサー記事を書きます。
これはクラウドアーキテクトという仕事に対するモヤモヤでもあります。同じモヤモヤ抱えている人の参考になれば幸いです。
ちなみにAWS歴は4年目、今年AWS All Certifications Engineersを取得しました。
アーキテクチャって何？
前提ですが、アーキテクチャというのは図にすると例えばこんな感じのものです。
こういうの一度どこかで見たことある人は多いんじゃないでしょうか。
上記は簡単な構成ですが、今年私が設計したアーキテクチャの1つです。
こういうのを作り終えたあと、大体わたしはモヤモヤしてしまいます。
モヤモヤの正体に迫る
みなさんは新しいシステムのアーキテクチャってどんな流れで考えていきますか？
私の場合は、大体いつも
- 要件の確認・整理
- 要件が近いシステムのアーキテクチャを探して参考にする
- ベストプラクティスに沿って要件を満たすようなアーキテクチャを図に起こす
- 社内レビュー、AWSの人によるレビューを行う
- （修正箇所があれば）レビューの内容を反映する
こんな感じの流れでアーキテクチャを考え、図に起こしていきます。よくある流れだと思います。
そして多少緊張しながら社内レビューやAWSの人によるレビューを終えた後「よしこれで行こう！」ってなったとき、ふと、
「これって俺じゃない人が作ったとしても同じようなアーキテクチャになったくね？」
と、思い突然虚無に陥ってしまいます。みなさんはそんな経験ありませんか？
少なくとも私はここ1年くらいこの感覚に陥ってました。なんで私はそう思ってしまうのでしょう？
それは恐らく
アーキテクチャには正解がある
と思っているからです。
皆さんもアーキテクチャには正解があると思っていませんか？
AWS アーキテクチャセンターやAWS Architecture Blogを覗けばまるで正解のようなアーキテクチャがたくさん載っていますし、アーキテクチャを考える際は、AWS Well-Architected Frameworkという教科書のようなドキュメントもあります。
ちょっとググればベストプラクティスと呼ばれる事例もたくさん出てきます。
こうした背景から、私はアーキテクチャを考えるということは、既存の設計のマネと社内レビューを通して正解率を高め、最後にAWSによるレビューによって100点のハンコを押してもらう。こんな感じに思っていました。
ただそうすると「正解があるってことは誰がこの仕事をやっていたとしても行き着いたゴールは一緒だろうし、となるとこの仕事ってぶっちゃけあまり価値ないんじゃね？」と考えてしまい、アーキテクトの仕事って実はそんなに意義がないんじゃないんだろうか？と思ってしまっていたのです。
これが私の中でここ1年くらい頭の中にあったモヤモヤの正体です。
モヤモヤへのアンサー
アーキテクチャに正解はありません。正解はないので誰が考えても同じアーキテクチャになるということはないし、仮に表面的には同じようなアーキテクチャになったとしても、変化を前提としているかどうかや細かいところで差がつくものです。
というのが、今私が至っている結論です。この結論に至る過程で出会った考え方を3つほど紹介します。
ベストプラクティスは正解ではない
「何を当たり前のことを・・・」とお思いの皆さんは問題ないと思いますが、私は当初ベストプラクティスがすべてだと思い込んでいました。いいアーキテクチャとはベストプラクティスに沿ったアーキテクチャだと。つまり、AWS Well-Architected Frameworkの6本の柱をすべて満たすような、そんなアーキテクチャが正解のアーキテクチャだと思い込んでいたのです。
今思えばこれはあり得ません。例えば、スタートアップ企業にとっては、リソースと予算が限られているため、全てのベストプラクティスを適用することが現実的ではないです。このような状況では、必要最小限のアーキテクチャ（可用性を多少犠牲にしてシングルAZ構成にするなど）に焦点を当て、段階的にシステムを拡張していく方が適していると言えます。
また、標準的なベストプラクティスが適切でないこともあります。高度なセキュリティが必要な金融業界では、標準的なセキュリティプラクティス以上の独自の対策が求められます。
このようにベストプラクティスはベストプラクティスでしかなく、正解ではないのです。
アーキテクチャは進化させるもの
アーキテクチャは1度考えたらそれで終わりと思っていました。だってアーキテクチャを途中で変更するなんてめっちゃ大変だしそんなことあんまりしないでしょ？
その考えが間違っていました。
先日AWS Partner Tech Study Dayというオフラインイベントに参加してきましたが、そこで「よいアーキテクチャは環境に適用しているもの」と言っていました。つまり、進化可能なものです。
例えば、プロダクトのフェーズによって重視すべき指標も変わってきます。初期はコストを抑え、その代わりに可用性はある程度犠牲にする。プロダクトが成長してユーザーが増えたら多少コストをかけてでもパフォーマンスを高めるようなアーキテクチャに変更する。そんな風にアーキテクチャも時間の経過とともに変化すべきなのです。
上記の例ではコストとパフォーマンスという簡単な指標を出しましたが、他にも考慮すべき指標はたくさんあります。例えばバグの数やリリースの頻度、テスト内容、組織の人数、開発者のAWSレベル、などありとあらゆる指標がアーキテクチャに影響を与える可能性があります。
環境の変化を見据えて今のアーキテクチャを考えることが出来るかどうかでアーキテクトとしての差がつくなと思いました。
ちなみにAWSのサービスが超豊富なのも進化可能なアーキテクチャを可能にするためらしいです。
アーキテクチャ図に表現されない部分で差がつく
AWSのアーキテクチャ図は、システムの基本構造とコンポーネントを視覚的に表現する一方で、成功するクラウドアーキテクチャの秘訣は、図に表現されてない部分だったりします。
例えばセキュリティとコンプライアンスにおいて、図では良くてセキュリティグループやIAMロールなどまで描きますが、実際のセキュリティポリシーの厳密さや運用の細かい部分までは表現されません。しかし、この表現されていない部分がアーキテクチャのセキュリティレベルを左右します。
他にもバックアップとディザスタリカバリの戦略について、図では単純なバックアップソリューションを示すかもしれませんが、実際には、ビジネスの継続性を保証するためには、詳細なリカバリ計画と定期的なテストが必要です。
このようにアーキテクチャ図で表現される部分というのはアーキテクトの仕事の氷山の一角でしかないのです。
さいごに
アーキテクトとしての仕事の意義を再認識することが出来ました。アーキテクトとしてキャリアを築いていくことに若干の不安を感じていましたが、今は不安はありません。まだまだ成長できる余地も感じています。
今考えればアーキテクチャに正解があると思い込んでいたのはAWS認定試験を通じて正解ばかりを追いかけていた弊害かもしれません。
AWSのイベントに参加することでいろんな考えに触れることが出来た結果、今回のモヤモヤが自然と解消されていったので今後も定期的に参加していきたいと思います。
それではみなさん、良い年末をお過ごしください。
参考