Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

マイクロサービスアーキテクチャでのフィーチャーフラグの活用方法

Posted at

ここでは、Go言語、gRPC、そしてKubernetes (k8s) を用いたマイクロサービスアーキテクチャにおいて、フィーチャーフラグをどのように活用できるか、特に小規模なサービスを対象に、初心者にも分かりやすく、具体的なディレクトリ構造とコード例を交えながら詳しく説明するのだ。

1. フィーチャーフラグとは何か、なぜ重要か

フィーチャーフラグ(Feature Flag、またはフィーチャートグルとも呼ばれる)とは、アプリケーションの特定機能を実行時に有効化または無効化するための仕組みである。コードを変更せずに、特定機能のリリースやロールバック、A/Bテストなどを制御できるようになるのだ。

マイクロサービスアーキテクチャでは、複数の独立したサービスが連携して動作するため、新機能のリリースや変更が複雑になりがちだ。フィーチャーフラグは、以下のような点で特に重要となる。

  • リスクの低減: 新機能をまずは一部のユーザーにだけ公開したり、問題発生時に即座に機能を無効化したりできる。
  • 迅速なデプロイ: 機能が未完成でも、フラグで無効化しておけば安全にコードを本番環境にデプロイできる(トランクベース開発との相性が良い)。
  • 柔軟なリリース管理: 特定の条件下(例:特定の地域、特定のユーザーグループ)でのみ機能を有効化できる。
  • A/Bテスト: 同じ機能の異なるバージョンを異なるユーザーグループに提供し、効果を比較できる。

小規模なサービスであっても、これらのメリットは十分に享受できる。むしろ、リソースが限られている小規模チームこそ、安全かつ迅速に開発を進めるためにフィーチャーフラグをうまく活用すべきなのだ。

2. フィーチャーフラグの導入戦略(小規模サービス向け)

大規模なシステムでは専用のフィーチャーフラグ管理サービス(LaunchDarkly, Unleashなど)を導入することが多いが、小規模なサービスではもっとシンプルな方法から始めることができる。

ここでは、設定ファイルKubernetesのConfigMapを利用した、比較的導入しやすい方法を中心に解説するのだ。

3. ディレクトリ構造の提案

Goマイクロサービスの一般的なディレクトリ構造をベースに、フィーチャーフラグ関連の要素を配置する例を示す。ここでは greeter という簡単なgRPCサービスを例にする。

my-feature-service/
├── cmd/
│   └── greeter-server/
│       └── main.go                # サーバー起動のエントリーポイント
├── internal/
│   ├── config/
│   │   └── config.go              # 設定(フィーチャーフラグ含む)の読み込み
│   ├── feature/
│   │   └── flags.go               # フィーチャーフラグの判定ロジック
│   ├── handler/
│   │   └── greeter_handler.go     # gRPCリクエストハンドラ
│   └── service/
│       └── greeter_service.go     # ビジネスロジック(今回はハンドラに統合も可)
├── pkg/                           # 他のサービスと共有する可能性のあるコード (今回は未使用)
├── proto/
│   └── greeter/
│       └── greeter.proto          # Protobuf定義ファイル
│       └── greeter.pb.go          # 生成されたGoコード
│       └── greeter_grpc.pb.go     # 生成されたGoコード (gRPC)
├── go.mod
├── go.sum
├── config.yaml                    # フィーチャーフラグの設定ファイル
└── kubernetes/
    ├── configmap.yaml             # Kubernetes ConfigMap定義
    └── deployment.yaml            # Kubernetes Deployment定義

この構造は一例であり、プロジェクトの規模やチームの慣習によって調整可能だ。

4. コード例

具体的なコードを見ながら、フィーチャーフラグの実装方法を見ていこう。

4.1. Protobuf定義 (proto/greeter/greeter.proto)

まずは、簡単なgRPCサービスを定義する。挨拶メッセージを返すだけのシンプルなサービスだ。

syntax = "proto3";

package greeter;

option go_package = "my-feature-service/proto/greeter";

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

この .proto ファイルからGoのコードを生成するには、protoc コンパイラと関連プラグインが必要だ。
以下のコマンドで生成できる(事前に protoc, protoc-gen-go, protoc-gen-go-grpc をインストールしておくこと)。

mkdir -p proto/greeter
protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    proto/greeter/greeter.proto

4.2. 設定ファイル (config.yaml)

フィーチャーフラグの状態を定義するYAMLファイルだ。アプリケーションはこのファイルを読み込んでフラグの状態を判断する。

features:
  newWelcomeMessage: true
  experimentalGreeting: false
  userSpecificFeature:
    enabled: true
    users: ["alice", "bob"]

ここでは3つのフラグを定義している。

  • newWelcomeMessage: 新しい歓迎メッセージを有効にするかどうか。
  • experimentalGreeting: 実験的な挨拶機能を有効にするかどうか。
  • userSpecificFeature: 特定のユーザーにのみ有効な機能。

4.3. 設定読み込み (internal/config/config.go)

config.yaml を読み込み、Goの構造体にマッピングする。

package config

import (
	"os"
	"log"
	"gopkg.in/yaml.v3"
)

type FeatureFlags struct {
	NewWelcomeMessage    bool                   `yaml:"newWelcomeMessage"`
	ExperimentalGreeting bool                   `yaml:"experimentalGreeting"`
	UserSpecificFeature  UserSpecificFeatureCfg `yaml:"userSpecificFeature"`
}

type UserSpecificFeatureCfg struct {
	Enabled bool     `yaml:"enabled"`
	Users   []string `yaml:"users"`
}

type Config struct {
	Features FeatureFlags `yaml:"features"`
}

var globalConfig *Config

func LoadConfig(configPath string) (*Config, error) {
	data, err := os.ReadFile(configPath)
	if err != nil {
		return nil, err
	}

	var cfg Config
	err = yaml.Unmarshal(data, &cfg)
	if err != nil {
		return nil, err
	}
	globalConfig = &cfg
	log.Println("Configuration loaded successfully.")
	log.Printf("Feature - NewWelcomeMessage: %v\n", cfg.Features.NewWelcomeMessage)
	log.Printf("Feature - ExperimentalGreeting: %v\n", cfg.Features.ExperimentalGreeting)
	log.Printf("Feature - UserSpecificFeature Enabled: %v for users: %v\n", cfg.Features.UserSpecificFeature.Enabled, cfg.Features.UserSpecificFeature.Users)
	return &cfg, nil
}

func GetConfig() *Config {
	if globalConfig == nil {
		// 本番環境ではエラー処理やデフォルト値の設定をより堅牢にすべきだ。
		// ここでは簡略化のため、LoadConfigが事前に呼ばれることを期待する。
		log.Fatal("Configuration not loaded. Call LoadConfig first.")
	}
	return globalConfig
}

このコードでは、gopkg.in/yaml.v3 パッケージを使ってYAMLファイルをパースしている。go get gopkg.in/yaml.v3 でインストールできる。
LoadConfig で読み込んだ設定は globalConfig 変数に保持され、GetConfig でどこからでもアクセスできるようにしている(シングルトンパターンの一種)。より高度な依存性注入の仕組みを使っても良い。

4.4. フィーチャーフラグ判定ロジック (internal/feature/flags.go)

フィーチャーフラグが有効かどうかを判定する関数群を定義する。

package feature

import (
	"my-feature-service/internal/config"
	"slices" // Go 1.21+
)

// IsNewWelcomeMessageEnabled は新しい歓迎メッセージ機能が有効かどうかを返す。
func IsNewWelcomeMessageEnabled() bool {
	cfg := config.GetConfig()
	return cfg.Features.NewWelcomeMessage
}

// IsExperimentalGreetingEnabled は実験的な挨拶機能が有効かどうかを返す。
func IsExperimentalGreetingEnabled() bool {
	cfg := config.GetConfig()
	return cfg.Features.ExperimentalGreeting
}

// IsUserSpecificFeatureEnabledFor は特定のユーザーに対して機能が有効かどうかを返す。
func IsUserSpecificFeatureEnabledFor(userName string) bool {
	cfg := config.GetConfig()
	if !cfg.Features.UserSpecificFeature.Enabled {
		return false
	}
	// Go 1.21以降で利用可能な slices.Contains を使用。
	// それ以前のバージョンではループで確認する。
	return slices.Contains(cfg.Features.UserSpecificFeature.Users, userName)
}

ここでは、config パッケージから設定を読み出し、各フラグの状態を返す単純な関数を定義している。
slices.Contains はGo 1.21から標準ライブラリに追加された。それ以前のバージョンでは自前でスライス内検索のロジックを実装する必要がある。

4.5. gRPCハンドラ (internal/handler/greeter_handler.go)

gRPCリクエストを処理するハンドラで、フィーチャーフラグを使って処理を分岐する。

package handler

import (
	"context"
	"fmt"
	pb "my-feature-service/proto/greeter"
	"my-feature-service/internal/feature"
	"log"
)

// Server は greeter.GreeterServer を実装する。
type GreeterServer struct {
	pb.UnimplementedGreeterServer // 将来のバージョンのための前方互換性
}

func NewGreeterServer() *GreeterServer {
	return &GreeterServer{}
}

func (s *GreeterServer) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
	log.Printf("Received SayHello request for name: %s", req.GetName())
	userName := req.GetName()
	message := ""

	if feature.IsNewWelcomeMessageEnabled() {
		message = fmt.Sprintf("✨ Welcome, %s! This is the new greeting! ✨", userName)
	} else {
		message = fmt.Sprintf("Hello, %s.", userName)
	}

	if feature.IsExperimentalGreetingEnabled() {
		message += " (You are seeing an experimental feature!)"
	}

	if feature.IsUserSpecificFeatureEnabledFor(userName) {
		message += fmt.Sprintf(" [SPECIAL FEATURE FOR %s ACTIVATED!]", userName)
	}

	log.Printf("Sending reply: %s", message)
	return &pb.HelloReply{Message: message}, nil
}

このハンドラでは、SayHello メソッドの中で先ほど定義した feature パッケージの関数を呼び出し、フラグの状態に応じて返すメッセージを動的に変更している。

4.6. メイン処理 (cmd/greeter-server/main.go)

gRPCサーバーを起動し、設定ファイルを読み込むエントリーポイントだ。

package main

import (
	"log"
	"net"
	"os"

	"google.golang.org/grpc"
	"my-feature-service/internal/config"
	"my-feature-service/internal/handler"
	pb "my-feature-service/proto/greeter"
)

const (
	defaultPort       = "50051"
	defaultConfigPath = "./config.yaml" // ローカル実行時のデフォルトパス
)

func main() {
	port := os.Getenv("PORT")
	if port == "" {
		port = defaultPort
	}

	configPath := os.Getenv("CONFIG_PATH")
	if configPath == "" {
		configPath = defaultConfigPath
	}

	// 設定ファイルの読み込み
	_, err := config.LoadConfig(configPath)
	if err != nil {
		log.Fatalf("Failed to load configuration: %v", err)
	}

	lis, err := net.Listen("tcp", ":"+port)
	if err != nil {
		log.Fatalf("Failed to listen: %v", err)
	}

	s := grpc.NewServer()
	greeterServer := handler.NewGreeterServer()
	pb.RegisterGreeterServer(s, greeterServer)

	log.Printf("Server listening at %v", lis.Addr())
	if err := s.Serve(lis); err != nil {
		log.Fatalf("Failed to serve: %v", err)
	}
}

環境変数 PORTCONFIG_PATH を使って、ポート番号と設定ファイルのパスを指定できるようにしている。
サーバー起動前に config.LoadConfig を呼び出してフィーチャーフラグの値を読み込んでいる。

5. Kubernetesでの運用

Kubernetes環境では、フィーチャーフラグの設定ファイル(config.yaml)をConfigMapとして管理し、Podにマウントするのが一般的だ。

5.1. ConfigMap定義 (kubernetes/configmap.yaml)

config.yaml の内容を保持するConfigMapを作成する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: greeter-config
  namespace: default # 環境に合わせて変更
data:
  config.yaml: |
    features:
      newWelcomeMessage: true
      experimentalGreeting: false
      userSpecificFeature:
        enabled: true
        users: ["alice", "bob", "charlie-from-k8s"]

このConfigMapを kubectl apply -f kubernetes/configmap.yaml でクラスタに適用する。

5.2. Deployment定義 (kubernetes/deployment.yaml)

Deployment定義で、ConfigMapをボリュームとしてPodにマウントし、アプリケーションが読み込めるようにする。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: greeter-service
  namespace: default # 環境に合わせて変更
  labels:
    app: greeter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: greeter
  template:
    metadata:
      labels:
        app: greeter
    spec:
      containers:
      - name: greeter-server
        image: your-repo/my-feature-service:latest # 作成したDockerイメージを指定
        ports:
        - containerPort: 50051
        env:
        - name: PORT
          value: "50051"
        - name: CONFIG_PATH # コンテナ内の設定ファイルパス
          value: "/app/config/config.yaml"
        volumeMounts:
        - name: config-volume
          mountPath: /app/config # マウント先のディレクトリ
          readOnly: true
      volumes:
      - name: config-volume
        configMap:
          name: greeter-config # 作成したConfigMapの名前
          items:
          - key: config.yaml
            path: config.yaml # マウントするファイル名

注意点:

  • your-repo/my-feature-service:latest は、実際にビルドしてプッシュしたDockerイメージのパスに置き換える必要がある。
  • CONFIG_PATH 環境変数で、Pod内の設定ファイルのパスをアプリケーションに伝えている。
  • ConfigMapは読み取り専用 (readOnly: true) でマウントするのが一般的だ。

5.3. Dockerfileの例

アプリケーションをコンテナ化するためのDockerfileの例。

# ビルドステージ
FROM golang:1.22-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

# protoファイルからGoコードを生成 (必要に応じて)
# RUN apt-get update && apt-get install -y protobuf-compiler
# RUN go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
# RUN go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
# RUN protoc --go_out=. --go_opt=paths=source_relative \
#     --go-grpc_out=. --go-grpc_opt=paths=source_relative \
#     proto/greeter/greeter.proto

RUN CGO_ENABLED=0 GOOS=linux go build -o /app/greeter-server ./cmd/greeter-server

# 実行ステージ
FROM alpine:latest

RUN apk --no-cache add ca-certificates

WORKDIR /app

# ビルドステージから実行ファイルと設定ファイルをコピー
COPY --from=builder /app/greeter-server /app/greeter-server
# COPY config.yaml /app/config.yaml # ConfigMapを使う場合は不要

# ポート開放
EXPOSE 50051

# 環境変数 (ConfigMapで上書きされるパスのデフォルト)
# ENV CONFIG_PATH=/app/config.yaml

# 実行コマンド
CMD ["/app/greeter-server"]

このDockerfileでは、マルチステージビルドを使用して軽量な実行イメージを作成している。
protoファイルの生成ステップは、ローカルで生成済みのファイルをコピーする場合はコメントアウトしても良い。
COPY config.yaml の行は、ConfigMapを使用する場合は不要になるためコメントアウトしている。アプリケーションはKubernetesがマウントしたパスから config.yaml を読み込む。

5.4. フィーチャーフラグの更新

フィーチャーフラグの値を変更したい場合は、以下の手順で行う。

  1. kubernetes/configmap.yaml ファイルの data セクションを編集してフラグの値を変更する。
  2. kubectl apply -f kubernetes/configmap.yaml を実行してConfigMapを更新する。
  3. 重要: ConfigMapを更新しただけでは、既存のPodは古い設定を使い続ける。新しい設定をPodに反映させるには、Podを再起動(ローリングアップデート)する必要がある。
    • Deploymentを再デプロイする: kubectl rollout restart deployment/greeter-service -n default
    • または、Deploymentの定義を少し変更して kubectl apply -f kubernetes/deployment.yaml を再度実行する(例: アノテーションを追加・変更するなど)。これによりローリングアップデートがトリガーされる。

アプリケーションが起動時に設定ファイルを読み込む実装になっているため、Podが再起動されると新しいConfigMapの内容が反映される。
もし、アプリケーションの再起動なしにフラグを動的に更新したい場合は、設定ファイルを定期的に再読み込みするロジックをアプリケーションに追加するか、KubernetesのReloaderのようなツールを使ってConfigMapやSecretの変更を検知してPodのローリングアップデートを自動化するなどの高度な仕組みが必要になる。小規模サービスでは、まずはPodの再起動で対応するのがシンプルだ。

6. 考慮事項とベストプラクティス

  • フラグの命名規則: 明確で一貫性のある命名規則を設ける(例: enableNewCheckoutFlow, showExperimentalDashboard)。
  • フラグのライフサイクル: フィーチャーフラグは一時的なものであるべきだ。機能が安定して全ユーザーに公開されたら、関連するフラグと分岐ロジックをコードから削除する(技術的負債の防止)。
  • テスト: フィーチャーフラグの各組み合わせ(有効/無効)でアプリケーションが正しく動作することを確認するテストを書く。
  • モニタリング: 各フィーチャーフラグの状態や、フラグによって有効化された機能のパフォーマンスを監視する。
  • スコープ: フラグの影響範囲を明確にする(全ユーザー向けか、特定ユーザー向けかなど)。
  • ドキュメンテーション: どのフラグが何のために存在し、どのような状態かを記録しておく。

7. まとめ

フィーチャーフラグは、Go、gRPC、Kubernetesを用いたマイクロサービス開発において、リリースプロセスの柔軟性と安全性を大幅に向上させる強力なツールだ。小規模なサービスであっても、設定ファイルとConfigMapを利用したシンプルな実装から始めることで、その恩恵を十分に受けることができる。

ここで紹介したディレクトリ構造やコード例はあくまで一例であり、プロジェクトの特性に合わせて適宜変更してほしい。重要なのは、フィーチャーフラグの概念を理解し、それを開発プロセスに組み込むことだ。これにより、より迅速かつ安全に価値をユーザーに届けられるようになるだろう。

0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?