はじめに
イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。
世の中に知られているベストプラクティスを取り入れて実践することは、目的ではなく手段。その先にある自分たちの事業・サービスに適した自分たちのベストプラクティスを確立することが、最初の目的だと思います。現実にはベストプラクティスというものは何処にも存在せず、永遠のベタープラクティスなのだと思います。
本記事は、これから自分たちにとってのベストプラクティスに向かう長い航海について、ベストプラクティスと内製開発体制の構築と絡めて、自分の想いを整理したいと思います。
ベストプラクティスをものにする難しさ
「ベストプラクティスの功罪」の章では下記の事柄が書かれています。
- 従来、お金をお金を払わないと入手できなかった知見やノウハウが容易に入手できるようになった。よい時代になった。
- しかし、それらを鵜呑みにして残念な結果に終わることも珍しくない。
同感です。書籍やWebで当たり前に語られているモダンな技術・手法は、やってみたレベルでは容易であっても、自分たちのチームでものにするには時間がかかります。更に、それを大人数にスケールアウトすることは想像以上に大変です。
技術的な課題はもとより、事業の背景、チームの構成・ビルディング、運用・保守、・・・課題はあらゆる領域に多岐に及び、正直、やってみないと分からない事が多いと思います。
ベストプラクティスと内製開発体制
私は、内製開発体制の構築は目的ではなく手段と思っています。世の中で知られているベストプラクティスを取り入れて、更に、自分たちにとってのベストプラクティスに早くたどり着くために有効な手段の一つだと考えます。
未知のものに取り組む訳ですので、正直、やってみないと分からないことが多いと思います。そのためには、いかに早く失敗をして早く改善するかが重要です。その際に大切にしている価値観は下記です。
- ミッション
- ・・・
- ビジョン (ミッションを達成したときにどんな世界が実現するのか？)
- ・・・
- バリュー (ミッション、ビジョン実現に向かう中での価値観)
- 当事者意識をもつ。
- 全てに対してオープンである。
- 心理的安全性の確保。対話の重視。
- 合意形成。合意形成とは、第三者が経緯・背景、課題、結論、結果の追跡が可能なこと。
ありきたりではありますが、ミッションとビジョンが何であっても、失敗を繰り返して改善していくことが必要な取り組みでは、これらの価値観は普遍的な項目だと考えています。また、独善的になりがちな自分自身を常に戒めるための言語化という面もあります。
ベストプラクティス(構想)
CI/CD
CI/CDパイプライン全体構成
目的
- デプロイ・リリース操作の自動化によるヒューマンエラーの防止。
- ソースコードの投入から実際のエンドユーザにサービスが展開されるまでの時間短縮。
方針
- CI/CD パイプラインは、基盤を構成する各サービスに対して以下の機能を提供する。
- 継続的インテグレーション (CI: Continuous Integration)
- 継続的デリバリー (CD: Continuous Delivery)
- アプリケーションのソースコード以外もCI/CDパイプラインの対象とする。
- アプリケーションの修正
- アプリケーションの設定変更
- データベースのマイグレーション
- インフラのリソース調整
CI(継続的インテグレーション)
対象Gitリポジトリの特定ブランチに対するソースコードの変更 (Git push) を検知して自動的に以下の処理を実行する。
- ソースコード (アプリケーション) のビルド
- ソースコード (アプリケーション) のテスト
- コンテナイメージのビルド
- コンテナイメージのセキュリティスキャン
- コンテナイメージをイメージレジストリへ格納
CIパイプラインの結果はリアタイムで把握し、エラーが発生した場合は迅速に次のアクションを取れるように仕組みを導入する。
- CIパイプラインの現在と過去の状況・結果は、ダッシュボードなどで確認が可能。
- CIパイプラインの結果は、Slackやemailなどを利用して、開発・運用者へ即座に通知 (アラート)。
CD(継続的デリバリー)
全ての変更を、必要に応じて、迅速に、安全に、かつ、継続的なリリースを実現する。エンドユーザに影響を与えることなく、通常の営業時間(サービス提供時間)を含むあらゆるタイミングで、ソフトウェアをリリース。本番環境に変更を加えることを可能にする。
- 継続的デリバリーの実現 (リリースプロセスの自動化)
- 開発環境/ステージング環境
- アプリケーションのGitリポジトリの変更検知による自動的なデプロイを行う。
- 本番環境
- アプリケーションのGitリポジトリの変更検知による自動的なデプロイは行わない。
- 管理画面などを通しての手作業は原則許容しない。
- GitOps
- システム全体を宣言的に記述してGitで管理する(IaC化)。
- CDが自動的にGitリポジトリの内容と実行環境の状態を同期する。
- 開発環境/ステージング環境
- Zero Downtime Deployment。アプリケーションの切り替え時のサービスダウンタイムを最小化する。原則、サービス利用者に対して使用不可期間の通知・連絡が不要なオーダーを実現する。
- アプリケーションに不備があった場合の切り戻しの迅速化。
CIパイプラインと同様にCDパイプラインの結果もリアタイムで把握し、エラーが発生した場合は迅速に次のアクションを取れるように仕組みを導入する。
- デプロイ状況は、ダッシュボードなどで確認が可能。
- デプロイ結果は、Slackやemailなどを利用して、開発・運用者へ即座に通知 (アラート)。
デリバリー戦略
- Rolling Update Deployment
- Blue-Green Deployment
- プログレッシブデリバリーは現時ではスコープ外
APIアプリケーションフレームワーク
Java vs. PHP ⇒ Java (Spring Boot) 選定
ASTで実装するシステムの特徴・傾向
- 各種システムとの連携など高度な処理が多い。
- 他システム、異なるクライアントから呼び出されることを想定する必要がある。
- システムが使用される期間は長く、長期的に会社の資産となるサービスが多い。
Spring Boot
- Quality > Delivery > Cost
- 既に開発・運用しているサービスでSpring Bootを使用しているケースが多く、長期的にASTでSpring Bootの知見をキャッチアップしていく必要あり。
- 優秀なエンジニアを確保しやすい。
- 高度な処理に対応出来る。
PHP
- Cost > Delivery > Quality
- 単純なWebシステム以外には向かない。
Batchアプリケーションフレームワーク
バッチジョブスケジューラ
- バッチジョブ実行要求の発行 (スケジュールド & 手動オンディマンド)
- ジョブネット(フロー制御)
- 原則、設定はコード化 (CI/CDにより反映される)
- 但し、運用管理の都合で必要な操作は、管理画面から管理者による手動操作を許容
- 例: 初期設定値 & ジョブネット(フロー制御)はコード化
- 例: 手動実行/一時停止などのオペレーションは管理画面経由UI操作
バッチ処理の実行環境
- バッチ処理実行用キューによるキューイング
- 1つのジョブは1つのPodで実行 (複数のジョブの同時実行可)
- サーバーリソースの効率化 (必要な分を必要な時に確保)
デプロイ戦略
- 個別のバッチ処理ごとに毎回イメージをpullする。
- 新版デプロイ(イメージ格納)後、バッチ処理は更新されたイメージを使用。
- デプロイに際してサービスを停止する必要性なし。
フロントエンド
Vue.js vs. React.js ⇒ React.js 選定
内製開発体制(構想)
ライフサイクル
リファレンスとプロダクト
「リファレンス設計」「リファレンス実装」「リファレンス実行環境」とは、単なるサンプルではなく、実際の開発や実装の際に手本とすべき標準という意味であり、商用リリース可能な品質を担保する成果物です。リファレンス実装（reference implementation）という言葉を拡大解釈して使用しています。
- 標準アーキテクチャ ＝ リファレンス設計 + リファレンス実装 + リファレンス実行環境
- 実プロダクトとの相互フィードバックを通して、双方の成長を図る。
チーム
チーム構成
- 組織横断型チーム
- 専任組織ではなく兼任人員でチーム構成
- ただし、元締めチームは専任人員で構成
- 理由
チームとプロダクトの関係
プロダクトとチームの関係
- 元締めチームーの責務
- 標準アーキテクチャとそのリファレンスのメンテナンス・進化。
- (共通) 各プロダクトチームと元締めチームとの知見・技術の相互フィードバック。
- プロダクトチーム所属のメンバーの責務
- 各プロダクトの内製開発のアーキテクチャと設計・実装のQCD。
- (共通) 各プロダクトチームと元締めチームとの知見・技術の相互フィードバック。
おわりに
書籍やWebで当たり前に語られているモダンな技術・手法は、やってみたレベルでは容易であっても、自分たちのチームでものにするには時間がかかります。更に、それを大人数にスケールアウトすることは想像以上に大変です。
ベストプラクティス(構想) を具現化するための技術選定として下記が考えられます。
- CI: GitHub Actions
- CD: ArgoCD
- k8s: kustomize
- バックエンド: Spring Boot
- フロントエンド: Next.js x Vercel / Azure Static Web Apps / etc..
これらをチュートリアルに沿って何か試してみるだけなら数時間も掛かりません。しかし、これらを利用して商用サービスとして展開するまで昇華して、自分たちのものにすることは一朝一夕にはいきません。更にそれを組織内でスケールアウトしていくことは、とても長い道のりです。
今となっては全く一般的なアーキテクチャや方法論で、目新しいものは特に何も無いと思います。しかし、まずは当たり前の事を当たり前に出来るようになって、早く世の中のベストプラクティスを実践・評価できる場に到達。その先に、私たちにとってのベストプラクティスを実現出来るようになりたいと考えています。
実際、Sagaパターンだとかイベントソーシングとか色々と関心事は多いのですが、今の自分(たち)には未だ未だファンタジーの世界ですので。
今後、私たちのチームがこれらをものにしていく過程での課題・学びを共有出来ればと思います。
絶賛採用中です！
イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です！
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください！
-
陸上自衛隊、航空自衛隊において装備の運用研究や他部隊に対する教育を行う部隊。 ↩︎
Discussion