AWS+PlantUML+Gitで柔らかい「見えるインフラ」を作る

柔らかい「見えるインフラ」を作る

初めに

書いている人

インフラ入門者です。
至らない点があればつついてご指導ください。

誰向けの記事？

• AWSでインフラを作る・作っている人
• 必要なタイミングで柔軟に変更に対応しつつ、それをチームで共有するために見える化もしないといけない人
• インフラを秘伝のレシピや封印された地雷原にせず、適切にバージョン管理の配下に置きたい方

つまり、ToB的な方向のプロジェクトでインフラを任されたけど、
仕様変更がちょくちょくあって、
しかも仕様書に合わせて更新するような自動化とか許されなくて、
いやーもうこまっちゃうなーってなってる人。

（ぼくはちがいます、ちがいますって。。。。ぷるぷる。。。）

なんでこの記事を書いたの？

この記事の文脈は
Infrastructure as Codeとか、
Configuration as Codeとかにあります。

横文字にすると難しそうですが、
バックエンドにもバージョン管理みたいなツールとか、
スモールステップなDX(開発者体験)とかを取り入れて、
「設計も構築も設定も、敷居を下げようぜ(超意訳)」
って考え方です。

そんな中で、図鑑の入ったドキュメントって、
手間のわりに評価にも成果にも結び付かなくて、
大事なはずなのにおざなりになるわけです。

しかし、ちょっとの工夫で自動化も夢じゃない！
ということで、その方法を書いておきます。
いつか僕の現場でも導入できる日を夢見て。。。

個別要素の説明

PlantUML

試すだけならオンラインのジェネレータでpngなどにしてもらえますが、
業務利用する場合はセキュリティのためにローカルでやります。

• 基本的にはこのページにある通りでできちゃいます。

  • Java環境を作って
  • plantuml.jarを落としてきて
  • java -jar plantuml.jar file.pumlを呼ぶ

• 個人的にはMarkdown Preview Enhancedを組み合わせて、UML付きのドキュメントを作るのがおすすめです。

無事にPlantUMLが導入できたら、UMLやその他もろもろ、開発でほしい図は大体これで賄えます。
見た目を気にしないなら。

PlantUMLでリッチなAWSのグラフが欲しい

問題は見た目ですね。

チームでの共有なら通常のPlantUMLの見た目でもよいですが、
お客様に説明するときは偉い人から「もう少し見た目を」と言われて、
ドキュメントをわざわざ華やかにするというお仕事が発生します（呪）

まあ、見た目の良いドキュメントは使っていて気分が良いので構いませんが、
どうせ変更されるのにというむなしさもあり。

そんなお仕事を気持ちよくさせてくれるのが、
PlantUMLのために公開されているAWSのライブラリです。（感謝）
https://github.com/milo-minderbinder/AWS-PlantUML

こちらのリポジトリを導入すると、
かなりリッチな見た目でAWSの構成を表現できます。

例えば、ユーザーからのコメントをフィルタリングして、
対応窓口の負担を減らしたい、という場合をサクッと図にしてみましょう。
(いろいろ省いてますが)

Gitで管理しよう

PlantUMLの最大の利点はテキストから生成できることですね。
上記のumlを生成するために必要なテキスト量はたったこれだけ。

@startuml
!define AWSPUML https://raw.githubusercontent.com/milo-minderbinder/AWS-PlantUML/release/18-2-22/dist

!includeurl AWSPUML/ApplicationServices/AmazonAPIGateway/AmazonAPIGateway.puml
!includeurl AWSPUML/common.puml
!includeurl AWSPUML/Storage/AmazonS3/AmazonS3.puml
!includeurl AWSPUML/Storage/AmazonS3/bucket/bucket.puml
!includeurl AWSPUML/Compute/AWSLambda/AWSLambda.puml
!includeurl AWSPUML/Compute/AWSLambda/LambdaFunction/LambdaFunction.puml

LAMBDAFUNCTION(push,UserComment)
        LAMBDAFUNCTION(filter,Filtering)

AMAZONAPIGATEWAY(api)

AMAZONS3(temp, "Temp")
AMAZONS3(date, "User data")

user1 -d-> api 
user2 -d-> api 
user3 -d-> api 

api --> push
push -d-> temp
temp -u-> filter
filter -d-> date
@enduml

テキストベースなので当然Gitで管理できて、
誰がいつ何の目的でどこを変更したのか、
そして最新版がどれなのか（）
確実に管理できるわけです。

どう変わるのか

上で乗せたユーザーのコメントに関する図をお客様に見せて、
「Filteringしたデータなんだけど、
ブラックリストのデータも作りたいからS3は二つにしてよ」
なんて言われた場合、これまでなら大きな手間でした。

今まで

お客様の前で直せる程度の変更なら良いですが、
だいたい面倒なので更新するために一度持ち帰り、
エンジニアに依頼して正しい構成になるように図を修正してもらい、
書き直した図で大丈夫かをお客様に再度確認してもらい、
確認をもらってからチーム全体に共有し、
今まで使っていたドキュメントから新しいドキュメントに切り替え、、、、

つまり、めんどくさい。

これから

しかし、これからはその場でささっと書き変えて、
OKをもらった状態でcustomer/orderブランチにコミット。
必要な人員をReveiwerに指定すればチェックも確実。
マージされれば、それが正しい仕様としてチームで共有できるわけです。

天国！

柔らかい「見えるインフラ」へ

正直に言えば、AWSに限らず、IaaSのサービスはだいたいGUIやデータ内容が複雑です。
「インフラ簡単になりました」は間違いじゃないですが、
「インフラ誰でも触れるようになりました」はまだ間違いです。

しかし、こうしたツールを使うことで敷居も下がりますし、
かかわるコミュニティが広がることで、
UIも含めたノウハウはより洗練されていくはずです。

願うなら、エクセルとZipで賄おうとする現場がなくなりますことを。。。。

追記

それぞれのサービスのアイコンについて、
一覧になっているページがないので、
とりあえずまとめて画像にしてPR出しています。

PRがマージされたら更新しますが、
それまで僕のリポジトリの画像フォルダのURLを置いておきます。

こういう感じで一覧にしたものを並べています。