インフラ担当じゃないけどIaC導入のため動いてます 〜akippaのインフラ近代化を目指す〜
こんにちは。akippa株式会社のエンジニア奥山です。
私の主な役割はakippaのオーナー様（駐車場を貸し出す側）向けの機能開発です。バックエンドエンジニアと呼ばれる職種です。
本稿はインフラ担当ではない私が、Infrastructure as Code (IaC)を通じてインフラ運用のお手伝いをしている話をシェアします。
手作業だらけのインフラ運用
akippaは長く続いているサービスなだけあり、システム構成や運用方法にレガシーな面が目立ちます。
特に本来なら自動化できる作業を手動で行うことが常態化しているのが一番の課題だと思います。
これらの作業に時間を取られ、システム改善に費やす時間が削られ、結局手作業を続けるしかない…という悪循環に陥っています。
手作業は怖い
つい先日私も本番環境への変更作業を行いましたが、ミスの許されない環境での手作業は恐ろしいですね…。
複雑な手順は属人化も招きやすいですし、自分含む未来のakippaエンジニアのためにできる限り自動化しておきたいです。
「IaCやりたいです」
Infrastructure as Code (IaC)はこんな状況を改善に導くための鍵の一つです。
IaCはざっくり言えば、サーバなどのインフラ構成をプログラムのようにコード化し管理する技術です。
プログラムなので、一度作ればテスト環境でも本番環境でもコマンド一回で同等の設定に変更できたりします。
「手作業でテスト環境を作り、テスト後に改めて本番環境を作る」という今の運用を思えば、ミスも減らせるし大幅な効率化が期待できます。
akippaでもIaCの導入案はあったものの、人手が足らず進められない状況でした。
そこで、ある程度IaCとそのツールであるTerraformに知見を持っている私が導入に名乗りを上げました。
導入に際し工夫したこと
せっかくIaCを導入し便利になっても、管理が属人化したら元も子もありません。
これから新しく入る方や、インフラに明るくないエンジニアでも、
読むだけで現状の設定を理解したり、多少の設定変更なら自力でできる状態を目指しています。
一例として、リソースを適切に分割した上で、ディレクトリ名に社内でのシステムの通称や開発チーム内での呼び方（フレームワーク名）などを用い、目当てのものが探しやすい構成を心掛けています。
以下、お見せできる範囲のディレクトリ図です（だいぶ省略してます）
...
└── modules
├── ...
...
└── server
├── admin
...
├── api
│ ├── app
│ │ ├── laravel
│ │ │ ├── cloudwatch_metric_alarm.tf
│ │ │ ├── ec2.tf
│ │ │ ├── elb.tf
│ │ │ └── main.tf
│ │ ├── partner
│ │ │ ├── ...
│ │ └── yii
│ │ ├── ...
│ └── web
│ ├── laravel
│ │ ├── ...
│ └── zend
│ ├── ...
├── batch
│ ├── laravel
│ │ ├── ...
│ └── zend
│ ├── ...
├── front
│ ├── laravel
│ │ ├── ...
│ └── zend
│ ├── ...
├── owner
│ ├── ...
└── partner
├── ...例えばLaravelのアプリ用APIサーバの設定はこのディレクトリを見る、等
なんとなくでも伝わるのではないでしょうか…？
一緒に困りごとを解決できる環境
冒頭にも書きましたが私はインフラ専門ではありません。
この規模のチームだとバックエンドがインフラを兼ねるのは珍しいことではないですが、それでも入社して間もない私を信じて任せてくれたことを嬉しく思います。
特に現環境の構成など手取り足取りレクチャーしてくださった、インフラエンジニアの山下さんにはいつも感謝しています。
これからもakippaのインフラ近代化に向けて一緒に頑張りましょう！
akippaをより良くするため、一緒に困りごとを解決してくれる仲間も募集中です。
本記事で興味を持って頂いた方、是非！
この記事が気に入ったらサポートをしてみませんか？