こんにちは。akippa株式会社でエンジニアをしている山下と申します。
2022年7月にakippaへ入社して以来、Productチームの一員として様々な業務に携わっています。DevOpsでいうところのOpsの立ち位置ですね。

• 他チームからの相談窓口

• 日々の機能改善やバグ修正

• AWSインフラの運用

この中でも「AWSインフラの運用」に焦点をあてて、現状の課題とそれを改善するための取り組みをご紹介していこうと思います。

後回しになりがちなインフラ改善

akippaはサービス開始以来もうすぐ10年という節目を迎えますが、今に至るまでの成長過程で、様々な機能追加や仕様変更を重ねてきています。

当然、よく言われる「技術的負債」もそれなりに溜まっており、皆それを何とかしたい、けれども人手が足りない、というベンチャーやスタートアップあるあるな状況です。

限られたリソースで負債の解消に取り組む場合、提供しているサービスの挙動や体験と直結しやすいアプリケーションレイヤーに、どうしてもウェイトがかかりがちですよね。

「今問題なく」動いてると、インフラの課題は後回しになりがちですが、いざ何かあった時の影響が甚大という点は、IT業界を問わずインフラの宿命です。これを何とか「いざ」に備えられる状態まで持っていきます。

重視するポイント

日々の業務もある中で改善を進めていくには、十分なHP/MPを確保しておくことが必要不可欠です。途中で頓挫してしまわないよう、重視するポイントを決めました。

• 一度にまとめて課題を解決しようとしない

  • このレイヤーのトラブルは影響が甚大

  • 想定影響範囲をできるだけ局所化する

• べき論に固執しすぎない

  • 「akippaでの最適解」をゴールにする

  • とはいえ、見直せるところは積極的に見直す

• コツコツ続ける

  • 諦めない

  • 楽しくやる

ファーストステップ

改善を進めると言っても、現状と課題が明らかになっていなくては話になりません。akippaのインフラは全面的にAWSを利用しているので、まずは現状構成を把握しながら課題を洗い出し、最初に取り組む課題を決めました。

アカウントの分割

以下は現在のakippaの簡単なAWSの構成ですが、本番環境と開発環境のリソースが1つのアカウントに混在しています。

VPCで適切な境界は区切られているものの、オペレーションミスなどのヒューマンエラーによるトラブルの懸念はどうしても拭えません。

また、クラウド運用で重要なコスト戦略を考えていくうえでも、この状況では把握や分析のハードルが高いため、本番環境とそれ以外でアカウントを分割する事にしました。

適切なマルチAZ構成

続いてakippaの基本的なAZ構成です。
ALBとRDS(Aurora)を利用することで、マルチAZのメリットである高可用性を享受しています。

しかしながら、EC2(Webサーバー)は特定のAZに偏って配置されているため、本来の高可用性のメリットを十分に活かしきれていません。

これは非常にもったいないので、EC2の配置を見直し、適切なマルチAZ構成をとる事にしました。

諦めずにコツコツと

アカウント分割・マルチAZ構成と、キーワードだけ拾うと取り組みはどちらもシンプル極まりないのですが、そこはそれ、長年サービスを運営してきた事情や経緯がたくさんあり、なかなか一筋縄では行かないのが現状です。

また、セキュリティ観点などで危険な部分は基本的な対策がされているため、ともすれば自分自身も「まぁ今の構成でも良いかな…」と甘い誘惑に駆られがちです。

しかしながら、重視するポイントでも言及したとおり、このレイヤーで何か起きた時はakippaのサービスにも甚大な影響を及ぼします。

サービスの安定稼動、ひいては自分も枕を高くして寝られる(これ大事)よう、今まさに小さな一歩を踏み出したのが現状です。

この改善をnoteでシリーズ化することで、自分に適切なプレッシャーをかけつつ、技術的な発信もしていこうと考えていますので、よろしければお付き合いください。

最後に

akippaでは、デザイナー・エンジニアを絶賛募集中です。

特にエンジニアリング領域では、インフラレイヤーのみならずアプリケーションレイヤーでも解決したい課題が山積みです。

自社サービスでのエンジニアリングや、脱レガシーといったキーワードに興味がある方は、是非是非ご応募ください。