スケールアウトされたクラウド データベース間のデータ移動

  • [アーティクル]

適用対象:Azure SQL Database

お客様がサービスとしてのソフトウェアの開発者で、突然、アプリが多大な要求を受けた場合、その増加に対応する必要があります。 そのため、データベース (シャード) を追加します。 データの整合性を破壊することなく、新しいデータベースにデータを再分散する方法 Split-Merge ツールを使用して、データを制約付きデータベースから新しいデータベースに移動します。

Split-Merge ツールは、Azure Web サービスとして実行されます。 管理者または開発者は、ツールを使用して、シャードレット (シャードからのデータ) を異なるデータベース (シャード) 間で移動します。 このツールは、シャード マップの管理を使用して、サービス メタデータ データベースを維持し、一貫したマッピングを保証します。

Overview

ダウンロード

Microsoft.Azure.SqlDatabase.ElasticScale.Service.SplitMerge

ドキュメント

  1. エラスティック データベース Split-Merge ツールに関するチュートリアル
  2. Split-Merge セキュリティの構成
  3. Split-Merge セキュリティの構成
  4. シャード マップの管理
  5. 既存のデータベースを移行してスケールアウト
  6. エラスティック データベース ツール
  7. Elastic Database ツールの用語集

Split-Merge ツールを使用する理由

  • 柔軟性

    アプリケーションは、Azure SQL Database の単一データベースの制限を超えて柔軟に拡張できる必要があります。 ツールを使用して、整合性を維持したまま、新しいデータベースに必要なデータを移動します。

  • 分割して増加

    爆発的な増加に対応するために全体的な容量を増やすには、容量ニーズを満たすために、データをシャーディングし、データを分散するデータベースの数を段階的に増やすことによって追加の容量を確保します。 これは分割機能の典型的な例です。

  • マージして縮小

    容量は、ビジネスの季節的な性質によって縮小させる必要があります。 このツールを使用すると、ビジネスの成長が鈍化したときに、より少ないスケール単位に縮小できます。 Elastic Scale の Split-Merge サービスのマージ機能は、この要件に対応しています。

  • シャードレットの移動によるホットスポットの管理

    データベースごとに複数のテナントがある場合、シャードレットをシャードに割り当てることが、一部のシャードの容量ボトルネックにつながります。 これには、シャードレットを再び割り当てたり、ビジー状態のシャードレットを新しいシャードや使用率の低いシャードに移動したりする操作が必要になります。

概念と主な機能

  • お客様側でホストされるサービス

    Split-Merge は、お客様側でホストされるサービスとして提供されます。 このサービスは、Microsoft Azure サブスクリプション内でデプロイし、ホストする必要があります。 NuGet からダウンロードするパッケージには構成テンプレートが含まれていて、これに特定のデプロイの情報を入力します。 詳細については、「 Elastic Scale の分割とマージ サービス チュートリアル 」を参照してください。 このサービスは Azure サブスクリプション内で実行されるため、サービスのセキュリティに関するほとんどの側面を制御および構成できます。 既定のテンプレートには、TLS、証明書ベースのクライアント認証、保存された資格情報の暗号化、DoS 対策、IP 制限を構成するためのオプションが含まれています。 セキュリティの側面については、「 Elastic Scale のセキュリティの構成」を参照してください。

    既定では、デプロイされたサービスは、1 つの worker ロールと 1 つの Web ロールを使用して実行されます。 それぞれは、Azure Cloud Services の A1 VM サイズを使用します。 これらの設定は、パッケージをデプロイするときに変更することはできませんが、実行中のクラウド サービスへのデプロイが成功した後に (Azure ポータルを通じて) 変更することができます。 技術的な理由により、複数のインスタンスに worker ロールを構成しないでください。

  • シャード マップの統合

    Split-Merge サービスは、アプリケーションのシャード マップと対話します。 Split-Merge サービスを使用して範囲を分割またはマージしたり、シャードレットをシャード間で移動したりするとき、サービスによってシャード マップが自動的に最新の状態に保たれます。 これを実現するために、サービスは、アプリケーションのシャード マップ マネージャー データベースに接続し、分割/マージ/移動要求の進行に伴って範囲とマッピングを管理します。 これにより、Split-Merge 操作が実行されているときにシャード マップが常に最新の状態を示すことが保証されます。 分割、マージ、およびシャードレットの移動操作は、シャードレットのバッチをソース シャードからターゲット シャードに移動することによって実装されます。 シャードレットの移動操作中、現在のバッチの対象のシャードレットは、シャード マップ内でオフラインとしてマークされ、 OpenConnectionForKey API を使用したデータ依存ルーティング接続に使用できなくなります。

  • 一貫性のあるシャードレットの接続

    シャードレットの新しいバッチのデータの移動が開始されると、シャードレットを格納しているシャードへの、シャード マップによって提供されるすべてのデータ依存ルーティング接続が強制終了されます。さらに不整合を回避するために、データの移動操作中は、シャード マップ API からのシャードレットへの後続の接続がブロックされます。 同じシャード上の他のシャードレットへの接続も強制終了されますが、再試行すると成功します。 バッチが移動されると、シャードレットがターゲット シャードに対して再びオンラインとしてマークされ、ソース データがソース シャードから削除されます。 すべてのシャードレットが移動されるまで、すべてのバッチに対してこの手順が実行されます。 これにより、完全な移動/分割/マージ操作の進行中に接続の強制終了操作が複数回実行されることになります。

  • シャードレットの可用性の管理

    前述のように、接続の強制終了をシャードレットの現在のバッチに制限すると、使用不可能となるシャードレットのスコープが一度に 1 つのバッチに限定されます。 これは、分割/マージ操作の進行中にすべてのシャードレットに対してシャード全体がオフラインになるような方法よりも好ましいアプローチです。 一度に移動する個別のシャードレットの数として定義されるバッチのサイズは、1 つの構成パラメーターです。 これは、アプリケーションの可用性とパフォーマンスのニーズに応じて、分割およびマージ操作ごとに定義できます。 シャード マップでロックされている範囲は、指定されたバッチ サイズよりも大きくなる場合があります。 これは、サービスによって、データ内のシャーディング キー値の実際の数がバッチ サイズとほぼ一致するように範囲のサイズが選択されるためです。 これは、シャーディング キー値の数がスパースな場合に関して特に覚えておく必要があります。

  • メタデータのストレージ

    Split-Merge サービスは、データベースを使用して、その状態を管理し、要求処理中のログを保持します。 ユーザーは、サブスクリプションにこのデータベースを作成し、このデータベースの接続文字列をサービス デプロイの構成ファイルに指定します。 ユーザーの組織の管理者も、要求の進行状況を確認したり、潜在的な障害に関する詳細な情報を調べたりするために、このデータベースに接続できます。

  • シャーディング対応

    Split-Merge サービスでは、(1) シャード化テーブル、(2) 参照テーブル、(3) 通常のテーブルが区別されます。 移動/分割/マージ操作のセマンティクスは、使用されるテーブルの種類によって異なり、次のように定義されます。

    • シャード化されたテーブル

      分割/マージ/移動操作により、ソース シャードからターゲット シャードにシャードレットが移動されます。 要求全体が正常に完了した後、これらのシャードレットはソース上に存在しません。 ターゲット テーブルは、ターゲット シャード上に存在する必要があり、操作の処理の前にターゲット範囲にデータが含まれていてはいけません。

    • 参照テーブル

      参照テーブルの場合、分割/マージ/移動操作により、ソース シャードからターゲット シャードにデータがコピーされます。 ただし、ターゲット上のテーブルに行が存在する場合、このテーブルのターゲット シャード上で変更はしません。 参照テーブルのコピー操作を処理するには、テーブルが空になっている必要があります。

    • その他のテーブル

      その他のテーブルは、分割/マージ操作のソースまたはターゲットのどちらかに存在することができます。 Split-Merge サービスでは、すべてのデータの移動またはコピー操作に関してこれらのテーブルは無視されます。 ただし、制約がある場合にこれらのテーブルが操作を妨げる可能性があることに注意してください。

      参照テーブルとシャード化テーブルに関する情報は、シャード マップの SchemaInfo API によって提供されます。 次の例では、特定のシャード マップ マネージャー オブジェクトでこれらの API を使用しています。

      // Create the schema annotations
SchemaInfo schemaInfo = new SchemaInfo();

// reference tables
schemaInfo.Add(new ReferenceTableInfo("dbo", "region"));
schemaInfo.Add(new ReferenceTableInfo("dbo", "nation"));

// sharded tables
schemaInfo.Add(new ShardedTableInfo("dbo", "customer", "C_CUSTKEY"));
schemaInfo.Add(new ShardedTableInfo("dbo", "orders", "O_CUSTKEY"));

// publish
smm.GetSchemaInfoCollection().Add(Configuration.ShardMapName, schemaInfo);

      region テーブルと nation テーブルは参照テーブルとして定義されており、分割、マージ、移動の各操作によってコピーされます。 一方、customer と orders はシャード化されたテーブルとして定義されています。 C_CUSTKEY と O_CUSTKEY はシャーディング キーとして機能します。

  • 参照整合性

    Split-Merge サービスは、テーブル間の依存関係を分析し、外部キーと主キーのリレーションシップを使用して、参照テーブルとシャードレットを移動する操作をステージングします。 一般に、最初に参照テーブルが依存関係の順にコピーされ、次にシャードレットが各バッチ内での依存関係の順にコピーされます。 これは、新しいデータが到着するときにターゲット シャード上の外部キーと主キーの制約が適用されるために必要な操作です。

  • シャード マップの整合性と最終的な完了

    エラーの場合、Split-Merge サービスは停止後に操作を再開して、進行中の要求を完了しようとします。 ただし、ターゲット シャードが失われた場合や、修復できないほど危害を受けている場合など、回復できない状況もあります。 このような状況では、移動されたと考えられるシャードレットがソース シャード上に残されたままになる場合があります。 このサービスでは、必要なデータがターゲットに正常にコピーされた後でのみシャードレット マッピングが更新されることが保証されます。 ソース上のシャードレットは、すべてのデータがターゲットにコピーされ、対応するマッピングが正常に更新された後で削除されます。 削除操作は、ターゲット シャード上で範囲が既にオンラインになっているときにバックグラウンドで実行されます。 Split-Merge サービスでは、シャード マップに格納されているマッピングの正確性が常に保証されます。

Split-Merge のユーザー インターフェイス

Split-Merge サービス パッケージには、worker ロールと Web ロールが含まれます。 Web ロールは、対話的に Split-Merge 要求を送信するために使用します。 ユーザー インターフェイスの主要なコンポーネントは、次のとおりです。

  • 操作の種類

    オプション ボタンを使用して、この要求に対してサービスによって実行される操作の種類を制御します。 分割、マージ、および移動のシナリオから選択することができます。 また、以前に送信した操作を取り消すこともできます。 範囲シャード マップに分割/マージ/移動要求を使用できます。 リスト シャード マップは、移動操作のみをサポートしています。

  • シャード マップ

    要求パラメーターの次のセクションでは、シャード マップと、シャード マップをホストするデータベースに関する情報を指定します。 具体的には、サーバーの名前、シャード マップをホストするデータベース、シャード マップ データベースに接続するための資格情報、および最後にシャード マップの名前を指定する必要があります。 現時点では、1 つの資格情報のセットのみを指定できます。 これらの資格情報には、シャード上のユーザー データだけでなく、シャード マップに対する変更を実行するための十分な権限が与えられている必要があります。

  • ソースの範囲 (分割とマージ)

    分割とマージ操作は、低値キーと高値キーを使用して範囲を処理します。 無制限の高値キーで操作を指定するには、"高キーは最大" チェック ボックスをオンにして、高値キー フィールドを空のままにしておきます。 指定する範囲のキー値はシャード マップ内のマッピングと境界に正確に一致する必要はありません。 範囲の境界を全く指定しない場合は、サービスは自動的に最も近い範囲を推論します。 GetMappings.ps1 PowerShell スクリプトを使用すると、特定のシャード マップの現在のマッピングを取得できます。

  • ソースの分割動作 (分割)

    分割操作の場合は、ソースの範囲を分割するポイントを定義します。 そのためには、分割操作を行うシャーディング キーを指定します。 オプション ボタンを使用して、範囲の前半 (分割キーを除きます) と後半 (分割キーを含みます) のどちらを移動するかを指定します。

  • ソース シャードレット (移動)

    移動操作は、ソースを示す範囲を必要としない点で、分割操作またはマージ操作とは異なります。 移動対象のソースは、移動しようとしているシャーディング キーの値によって識別されます。

  • ターゲット シャード (分割)

    分割操作のソースに関する情報を指定した場合は、ターゲットのサーバーとデータベース名を指定してデータのコピー先を定義する必要があります。

  • ターゲットの範囲 (マージ)

    マージ操作は、シャードレットを既存のシャードに移動します。 マージする既存の範囲の範囲境界を指定して既存のシャードを識別します。

  • バッチ サイズ

    バッチ サイズは、データ移動中に一度にオフライン化されるシャードレットの数を制御します。 バッチ サイズは整数値で指定します。シャードレットの長いダウンタイムを避けるには、小さな値を使用します。 大きな値を指定すると、特定のシャードレットがオフラインになる時間が長くなりますが、パフォーマンスが向上する場合があります。

  • 操作 ID (キャンセル)

    実行中の操作が不要になった場合は、対応するフィールドに操作 ID を指定することにより、操作を取り消すことができます。 操作 ID は、要求状態テーブル (セクション 8.1 を参照) または要求を送信した Web ブラウザーの出力から取得できます。

要件と制限事項

Split-Merge サービスの現在の実装には、次の要件と制限が適用されます。

  • シャードに対して Split-Merge 操作を実行する前に、シャードが存在し、シャード マップに登録されている必要があります。
  • このサービスは、操作の一部としてテーブルやその他のデータベース オブジェクトを自動的に作成しません。 これは、分割/マージ/移動操作を開始する前に、ターゲット シャード上にすべてのシャード化テーブルと参照テーブルのスキーマが存在している必要があることを意味します。 特に、シャード化テーブルは、移動/分割/マージ操作で新しいシャードレットが追加される範囲内で空になっている必要があります。 そうでないと、ターゲット シャードでの初期の整合性チェックで不合格になります。 また、参照データは参照テーブルが空の場合にのみコピーされる点と、参照テーブルに対する他の同時書き込み操作に関して一貫性が保証されない点にも注意してください。 分割/マージ操作を実行したときに、参照テーブルに変更を加える他の書き込み操作がないことを確認することをお勧めします。
  • サービスでは、大きなシャードレットのパフォーマンスと信頼性を向上させるために、シャーディング キーを含む一意のインデックスまたはキーで設定される行 ID に依存しています。 これにより、単なるシャーディング キー値よりも細かな粒度でデータを移動できます。 その結果、ログ領域と操作中に必要になるロックの量を削減できます。 移動/分割/マージ要求でテーブルを使用する場合は、シャーディング キーを含む一意のインデックスまたは主キーをテーブルに作成することを検討してください。 パフォーマンス上の理由により、シャーディング キーは、キーまたはインデックスの先頭の列である必要があります。
  • 要求の処理の過程で、一部のシャードレット データがソース シャードとターゲット シャードの両方に存在することがあります。 これは、シャードレットの移動時のエラーから保護するために必要です。 Split-Merge とシャード マップの統合により、シャード マップ上で OpenConnectionForKey メソッドを使用するデータ依存ルーティング API を介した接続において、中間状態の一貫性が失われることはありません。 ただし、 OpenConnectionForKey メソッドを使用せずにソース シャードまたはターゲット シャードに接続するときは、移動/分割/マージ要求の実行中に一貫性のない中間状態が発生する可能性があります。 これらの接続では、タイミングや接続の基になるシャードによって、部分的な結果や重複する結果が生成される可能性があります。 現在、この制限には、Elastic Scale マルチシャード クエリによって確立される接続が含まれます。
  • Split-Merge サービスのメタデータ データベースは、異なるロール間では共有できません。 たとえば、ステージング環境で実行されている Split-Merge サービスのロールは、実稼働環境ロールとは異なるメタデータ データベースを指し示す必要があります。

課金

Split-Merge サービスは、Microsoft Azure サブスクリプションのクラウド サービスとして実行されます。 そのため、クラウド サービスの料金がサービスのインスタンスに適用されます。 移動/分割/マージ操作を頻繁に実行する場合を除き、Split-Merge クラウド サービスを削除することをお勧めします。 こうすることで、実行中のまたはデプロイされたクラウド サービス インスタンスに対して発生するコストを削減できます。 分割/マージの操作を実行する必要があるときはいつでも簡単に実行可能な構成を再デプロイして開始することができます。

監視

状態テーブル

Split-Merge サービスでは、完了した要求と実行中の要求を監視するための RequestStatus テーブルがメタデータ ストア データベースに用意されています。 このテーブルには、この Split-Merge サービスのインスタンスに送信されたそれぞれの Split-Merge 要求データが行として含まれます。 それぞれの要求に対して、次の情報が含まれます。

  • Timestamp

    要求が開始されたときの日付と時刻。

  • OperationId

    要求を一意に識別する GUID。 この要求を使用して、まだ実行中の操作を取り消すこともできます。

  • 状態

    要求の現在の状態。 実行中の要求に対しては、要求の現在のフェーズも表示されます。

  • CancelRequest

    要求が取り消されたかどうかを示すフラグ。

  • 進行状況

    推定される操作の進捗状況。 値 50 は、操作が約 50% 完了していることを示します。

  • 詳細

    詳細な進捗状況レポートを提供する XML 値。 行のセットがソースからターゲットにコピーされるときに、進捗状況レポートが定期的に更新されます。 エラーまたは例外が発生した場合、この列にはエラーに関するより詳細な情報も含まれます。

Azure Diagnostics

Split-Merge サービスは、監視と診断を行うために Azure SDK 2.5 に基づく Azure Diagnostics を使用します。 診断構成を制御する方法については、次の記事で説明されています。Azure Cloud Services と Virtual Machines の診断機能の有効化に関する記事 ダウンロード パッケージには、Web ロール用と worker ロール用の 2 つの診断構成が含まれています。 これには、パフォーマンス カウンター、IIS ログ、Windows イベント ログ、および Split-Merge アプリケーション イベント ログを記録するための定義が含まれます。

診断のデプロイ

Note

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

重要

PowerShell Azure Resource Manager モジュールは引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。 これらのコマンドレットについては、「AzureRM.Sql」を参照してください。 Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。

NuGet パッケージで提供される Web ロール用と worker ロール用の診断構成を使用して、監視と診断を有効にするには、Azure PowerShell を使用して次のコマンドを実行します。

$storageName = "<azureStorageAccount>"
$key = "<azureStorageAccountKey"
$storageContext = New-AzStorageContext -StorageAccountName $storageName -StorageAccountKey $key
$configPath = "<filePath>\SplitMergeWebContent.diagnostics.xml"
$serviceName = "<cloudServiceName>"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWeb"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWorker"

診断設定を構成してデプロイする方法の詳細については、次の記事で説明されています:Azure Cloud Services と Virtual Machines の診断機能の有効化に関する記事

診断の取得

診断には、Visual Studio サーバー エクスプローラーのサーバー エクスプローラー ツリーの Azure の部分から簡単にアクセスできます。 Visual Studio インスタンスを開き、メニュー バーで [ビュー]、[サーバー エクスプローラー] の順にクリックします。 Azure のアイコンをクリックして Azure サブスクリプションに接続します。 次に、Azure -> [ストレージ] -> [<your storage account>] -> [テーブル] -> [WADLogsTable] の順に移動します。 詳しくは、「Server Explorer」(サーバー エクスプローラー) をご覧ください。

WADLogsTable

上の図で強調表示されている WADLogsTable には、スプリット-マージ サービスのアプリケーション ログからの詳細なイベントが含まれています。 ダウンロードしたパッケージの既定の構成は、運用環境のデプロイを対象にしていることに注意してください。 そのため、サービス インスタンスからログおよびカウンターが取得される間隔が長くなっています (5 分)。 テストと開発用には、Web ロールまたは worker ロールの診断設定をニーズに合わせて調整して、間隔を短くすることができます。 Visual Studio サーバー エクスプローラー (上図参照) でロールを右クリックし、[診断構成] 設定ダイアログ ボックスで、[転送間隔] の値を調整します。

Configuration

パフォーマンス

一般に、上位のより高パフォーマンスのサービス階層ほど、より高いパフォーマンスを期待できます。 上位のサービス階層で提供されるより優れた IO、CPU、およびメモリ割り当ては、Split-Merge サービスが使用する一括コピーおよび削除操作に役立ちます。 そのため、定義された一定期間のデータベースに対してのみサービス階層を増やします。

サービスでは、検証クエリが通常の操作の一部としても実行されます。 検証クエリは、ターゲット範囲に想定外のデータが存在していないことを確認して、すべての分割/マージ/移動操作が一貫性のある状態で開始されることを保証します。 これらのクエリは、操作のスコープと要求の定義の一部として提供されたバッチ サイズによって定義されたシャーディング キー範囲に作用します。 これらのクエリは、先頭の列にシャーディング キーを含むインデックスがあるときに最高のパフォーマンスを発揮します。

さらに、先頭の列にシャーディング キーを含む一意性プロパティにより、サービスは、ログ領域とメモリに関してリソースの消費を制限する最適化されたアプローチを使用できます。 (一般的に 1 GB 以上の) 大きなサイズのデータを移動するには、この一意性プロパティが必要です。

アップグレードする方法

  1. 「 Split-Merge サービスのデプロイ」の手順に従います。
  2. Split-Merge のデプロイ用のクラウド サービス構成ファイルを変更して、新しい構成パラメーターを反映します。 新しい必須のパラメーターは、暗号化に使用される証明書に関する情報です。 これを簡単に行うには、ダウンロードした新しい構成テンプレート ファイルを既存の構成と比較します。 Web ロールと worker ロールの両方の DataEncryptionPrimaryCertificateThumbprint と DataEncryptionPrimary に、必ず設定を追加するようにしてください。
  3. Azure に更新をデプロイする前に、現在実行中のすべての Split-Merge 操作が完了していることを確認します。 これは、実行中の要求の Split-Merge メタデータのデータベースで RequestStatus と PendingWorkflows テーブルを照会することで簡単に行えます。
  4. 新しいパッケージと更新されたサービス構成ファイルで、Azure サブスクリプションの Split-Merge の既存のクラウド サービスのデプロイを更新します。

アップグレードするために Split-Merge の新しいメタデータ データベースをプロビジョニングする必要はありません。 新しいバージョンは、既存のメタデータ データベースを新しいバージョンに自動的にアップグレードします。

ベスト プラクティスとトラブルシューティング

  • テスト テナントを定義し、複数のシャードにまたがるテスト テナントで最も重要な分割/マージ/移動操作を実行します。 すべてのメタデータが適切にシャード マップ内に定義され、操作が制約または外部キーに違反しないことを確認できます。
  • データ サイズに関連する問題が発生するのを防ぐには、テスト テナントのデータのサイズを、最大のテナントの最大データ サイズよりも大きく保ちます。 これは、1 つのテナントの移動にかかる時間の上限を評価する場合にも役立ちます。
  • スキーマで削除が許可されることを確認します。 Split-Merge サービスを使用するには、データがターゲットに正常にコピーされた後でソース シャードからデータを削除できる必要があります。 たとえば、 トリガーを削除する と、サービスがソースのデータを削除できなくなり、操作が失敗することがあります。
  • シャーディング キーが主キーまたは一意のインデックスの定義の先頭の列であることを確認します。 これにより、分割/マージ検証クエリと、シャーディング キー範囲に常に作用する実際のデータの移動と削除操作の最善のパフォーマンスが保証されます。
  • データベースが配置されているリージョンとデータ センターに Split-Merge サービスを併置します。

その他のリソース

まだ弾力性データベース ツールを使用していない場合は、 ファースト ステップ ガイドを参照してください。 ご質問がある場合は、SQL Database に関する Microsoft Q&A 質問ページを参照してください。機能に関するご要望は、SQL Database に関するフィードバック フォーラムで新しいアイデアを追加したり、既存のアイデアに投票したりしてください。