Share via

マイクロサービスの評価と準備

  • [アーティクル]

マイクロサービス アーキテクチャは、機敏性、スケーラビリティ、高可用性など、アプリケーションに多くの利点をもたらします。 これらの利点と共に、このアーキテクチャには課題があります。 マイクロサービスベースのアプリケーションを構築する場合、または既存のアプリケーションをマイクロサービス アーキテクチャに変換する場合は、現在の状況を分析して評価し、改善が必要な領域を特定する必要があります。

このガイドは、マイクロサービス アーキテクチャに移行するときに注意すべき考慮事項を理解するために役立ちます。 このガイドを使用して、アプリケーション、インフラストラクチャ、DevOps、開発モデルなどの成熟度を評価できます。

ビジネスの優先順位を理解する

マイクロサービス アーキテクチャの評価を開始するには、まずビジネスの主要な優先順位を理解する必要があります。 主要な優先順位は、機敏性、変更の導入、迅速な開発などに関連している場合があります。 アーキテクチャが主要な優先順位に適しているかどうかを分析する必要があります。 ビジネスの優先順位は時間の経過に伴い変化する可能性がある点に注意してください。 たとえば、イノベーションはスタートアップ企業にとって最優先事項ですが、数年後の主要な優先順位は信頼性と効率性になる場合があります。

考慮すべきいくつかの優先順位を次に示します。

  • イノベーション
  • [信頼性]
  • 効率性

組織のコミットメントを確保するために、アプリケーションのさまざまな部分と一致する SLA を文書化します。これは、評価のガイドとして役立つことがあります。

アーキテクチャに関する決定を記録する

マイクロサービス アーキテクチャは、チームが自律的になるために役立ちます。 チームは、テクノロジ、方法論、インフラストラクチャ コンポーネントなどについて自分たちで決定できます。 ただし、これらの選択では、共有ガバナンスと呼ばれる正式に合意された原則を尊重する必要があります。これは、マイクロサービスのより広範な戦略に取り組む方法に関するチーム間の合意を表します。

次の点を考慮します。

  • 共有ガバナンスは整っていますか?
  • アーキテクチャ ジャーナルで決定事項とそのトレードオフを追跡しますか?
  • チームはアーキテクチャ ジャーナルに簡単にアクセスできますか?
  • ツール、テクノロジ、フレームワークを評価するプロセスはありますか?

チーム構成を評価する

チーム間の不要なコミュニケーションを避けるためには、適切なチーム構造が必要です。 マイクロサービス アーキテクチャでは、小規模で集中型の部門連係チームの形成が促進され、チームの再構築に先だって考え方を変える必要があります。

次の点を考慮します。

  • チームは、ドメイン駆動設計 (DDD) の原則に従って、サブドメインに基づいて分割されていますか?
  • チームは、関連するマイクロサービスを個別に構築して運用するために十分なキャパシティを備えた部門連係型ですか?
  • プロジェクトに関連しないアドホック アクティビティとタスクに費やされる時間はどのくらいですか?
  • チーム間の共同作業に費やされる時間はどのくらいですか?
  • 技術的負債を特定して最小化するためのプロセスはありますか?
  • 学んだ教訓と経験はチーム間でどのように伝達されますか?

Twelve-Factor 方法論を使用する

マイクロサービス アーキテクチャを選択する基本的な目標は、アジャイル手法に従って、より速く価値を実現し、変化に適応することです。 Twelve-Factor App 方法論は、保守性に優れたスケーラブルなアプリケーションを構築するためのガイドラインを提供しています。 これらのガイドラインは、不変性、短命性、宣言型構成、自動化などの属性を促進します。 これらのガイドラインを組み込み、一般的に潜在する危険を回避することで、疎結合された自己完結型マイクロサービスを作成できます。

分解アプローチを理解する

モノリシック アプリケーションをマイクロサービス アーキテクチャに変換するには時間がかかります。 エッジ サービスから始めてください。 エッジ サービスは、他のサービスへの依存関係が少なく、独立したサービスとしてシステムから簡単に分解できます。 すべてのサービスが個別のマイクロサービスに分解されるまでモノリシック アプリケーションを動作状態に保つために、ストラングラー フィグや破損対策レイヤーなどのパターンを強くお勧めします。 分離中、DDD の原則は、チームがサブドメインに基づいてモノリシック アプリケーションからコンポーネントまたはサービスを選択するために役立ちます。

たとえば、eコマース システムでは、カート、製品管理、注文管理、価格、請求書の生成、通知といったモジュールがあります。 他のモジュールへの依存関係がないため、通知モジュールを使用してアプリケーションの変換を開始することにしました。 ただし、他のモジュールが、このモジュールに依存して通知を送信している場合があります。 通知モジュールは簡単に個別のマイクロサービスに分解できますが、新しい通知サービスを呼び出すには、モノリシック アプリケーションでいくつかの変更を加える必要があります。 次に、請求書生成モジュールを変換するものとします。 このモジュールは、注文が生成された後に呼び出されます。 ストラングラーや破損対策などのパターンを使用して、この変換をサポートできます。

データ同期、モノリシック インターフェイスとマイクロサービス インターフェイスの両方へのマルチ書き込み、データの所有権、スキーマの分解、結合、データ量、およびデータ整合性によって、データのブレークダウンと移行が困難になる可能性があります。 マイクロサービス間での共有データベースの保持、ビジネス機能またはドメインに基づくサービスグループからのデータベースの切り離し、サービスからのデータベースの分離など、いくつかの手法を使用できます。 推奨されるソリューションは、各サービスを備えた各データベースを分解することです。 多くの状況では、それは実用的ではありません。 そのような場合は、データベース ビュー パターンやデータベース ラッピング サービス パターンなどのパターンを使用できます。

DevOps の準備状況を評価する

マイクロサービス アーキテクチャに移行する場合は、DevOps の能力を評価することが重要です。 マイクロサービス アーキテクチャは、組織の機敏性を高めるためにアプリケーションでのアジャイル開発を容易にすることを目的としています。 DevOps は、この能力を達成するために実装する必要がある主要なプラクティスの 1 つです。

マイクロサービス アーキテクチャに関する DevOps の能力を評価する場合は、次の点に注意してください。

  • 組織内のユーザーは、DevOps の基本的なプラクティスと原則を知っていますか?
  • チームはソース管理ツールとそれらの CI/CD パイプラインとの統合を理解していますか?
  • DevOps プラクティスを適切に実装していますか?
    • アジャイル プラクティスに従っていますか?
    • 継続的インテグレーションは実装されていますか?
    • 継続的デリバリーは実装されていますか?
    • 継続的デプロイは実装されていますか?
    • 継続的監視は実装されていますか?
    • Infrastructure as Code (IaC) の準備は整っていますか?
  • CI/CD をサポートするために適切なツールを使用していますか?
  • ステージング環境と運用環境の構成は、アプリケーションに対してどのように管理されていますか?
  • ツール チェーンにはコミュニティ サポートとサポート モデルが含まれ、適切なチャンネルとドキュメントが提供されていますか?

頻繁に変化するビジネス領域を特定する

マイクロサービス アーキテクチャは柔軟で適応性に優れています。 評価中に、組織内のディスカッションを進め、同僚が頻繁に変わると考えている領域を決定します。 マイクロサービスを構築することで、チームは顧客が要求した変更に迅速に対応し、回帰テストの作業を最小限に抑えることができます。 モノリシック アプリケーションでは、1 つのモジュールの 1 か所の変更に、数多くのレベルの回帰テストが必要となり、新しいバージョンをリリースする機敏性が低下します。

次の点を考慮します。

  • サービスは個別にデプロイできますか?
  • サービスは DDD の原則に従っていますか?
  • サービスは SOLID の原則に従っていますか?
  • データベースはサービスに対して非公開ですか?
  • サポートされているマイクロサービス シャーシ パターンを使用してサービスを構築しましたか?

インフラストラクチャの準備状況を評価する

マイクロサービス アーキテクチャに移行する場合、インフラストラクチャの準備状況は考慮すべき重要なポイントです。 インフラストラクチャが適切に設定されていない場合、または適切なサービスやコンポーネントが使用されていない場合、アプリケーションのパフォーマンス、可用性、スケーラビリティに影響を及ぼします。 場合によっては、アプリケーションは推奨されるすべての方法論とプロシージャを用いて作成されているが、インフラストラクチャが不適切なことがあります。 この結果、パフォーマンスとメンテナンスが不十分になります。

インフラストラクチャの準備状況を評価する場合は、次の要因を考慮してください。

  • インフラストラクチャによって、デプロイされたサービスのスケーラビリティは確保されますか?
  • インフラストラクチャは、CI/CD を介して自動化できるスクリプトを使用したプロビジョニングをサポートしていますか?
  • デプロイ インフラストラクチャでは、可用性のための SLA が提供されますか?
  • ディザスター リカバリー (DR) プランと定期的な訓練スケジュールはありますか?
  • データは、DR のデータは異なる領域にレプリケートされますか?
  • データ バックアップ プランはありますか?
  • デプロイ オプションはに文書化されていますか?
  • デプロイ インフラストラクチャは監視されていますか?
  • デプロイ インフラストラクチャはサービスの自己復旧をサポートしていますか?

リリース サイクルを評価する

マイクロサービスは変更に適応し、アジャイル開発を利用してリリース サイクルを短縮し、顧客により多くの価値をもたらします。 リリース サイクルを評価する場合は、次の要因を考慮してください。

  • どのくらいの頻度でアプリケーションをビルドしてリリースしますか?
  • デプロイ後にリリースが失敗する頻度はどのくらいですか?
  • 停止後に問題を復旧または修復するためにどのくらいの時間を要しますか?
  • アプリケーションにセマンティック バージョニングを使用していますか?
  • 異なる環境を維持し、同じリリースを順次 (たとえば、最初にステージング、次に運用) 反映していますか?
  • API にバージョン管理を使用していますか?
  • API の適切なバージョン管理ガイドラインに従っていますか?
  • いつ、API のバージョンを変更していますか?
  • API のバージョン管理を処理するアプローチは何ですか?
    • URI パスのバージョン管理
    • クエリ パラメーターのバージョン管理
    • コンテンツタイプのバージョン管理
    • カスタム ヘッダーのバージョン管理
  • イベントのバージョン管理を行うためのプラクティスはありますか?

サービス間の通信を評価する

マイクロサービスは、ビジネス シナリオに対処するためにプロセスの境界を越えて相互に通信する自己完結型サービスです。 信頼性の高い通信を実現するには、適切な通信プロトコルを選択する必要があります。

次の要素を考慮してください。

  • API を最重要として取り扱う API ファースト アプローチに従っていますか?
  • 同期通信プロトコルを介して複数のサービスが順番に通信する、長いチェーン操作はありますか?
  • システム内のどこかで非同期通信を検討しましたか?
  • メッセージ ブローカー テクノロジとその機能を評価しましたか?
  • サービスが受信して処理するメッセージのスループットを理解していますか?
  • クライアントとサービス間で直接通信を使用しますか?
  • メッセージ ブローカー レベルでメッセージを保持する必要がありますか?
  • マイクロサービスのくだけた動作に対処するために具体化されたビュー パターンを使用していますか?
  • 信頼性の高い通信のために、再試行、サーキット ブレーカー、エクスポネンシャル バックオフ、ジッターを実装しましたか? これを処理する一般的な方法は、アンバサダー パターンを使用することです。
  • マイクロサービス間の通信を容易にするためにドメイン イベントを定義していますか?

サービスがクライアントに公開される方法を評価する

API ゲートウェイは、マイクロサービス アーキテクチャのコア コンポーネントの 1 つです。 サービスをクライアントに直接公開すると、管理の容易さ、制御、高信頼の通信の点で問題が発生します。 API ゲートウェイはプロキシ サーバーとして機能し、トラフィックをインターセプトして、それをバックエンド サービスにルーティングします。 IP アドレス、認可、モック応答などによってトラフィックをフィルターする必要がある場合は、サービスを変更することなく API ゲートウェイ レベルで実行できます。

次の要素を考慮してください。

  • サービスはクライアントによって直接使用されますか?
  • すべてのサービスのファサードとして機能する API ゲートウェイはありますか?
  • API ゲートウェイは、クォータ制限、モック応答、IP アドレスのフィルタリングなどのポリシーを設定できますか?
  • モバイル アプリ、Web アプリ、パートナーなど、さまざまな種類のクライアントのニーズに対応するために、複数の API ゲートウェイを使用していますか?
  • API ゲートウェイには、Azure API Management の開発者ポータルなど、クライアントがサービスを検出してサブスクライブできるポータルが用意されていますか?
  • ソリューションは、API ゲートウェイと共に L7 負荷分散Web Application Firewall (WAF) 機能を提供していますか?

トランザクションの処理を評価する

分散トランザクションを使用すると、単一の作業単位として複数の操作を容易に実行できます。 マイクロサービス アーキテクチャでは、システムは多数のサービスに分解されます。 単一のビジネス ユース ケースは、単一の分散トランザクションの一部として複数のマイクロサービスによって対応されます。 分散トランザクションでは、コマンドはイベントの発生時に開始される操作です。 イベントは、システム内で操作をトリガーします。 操作が成功すると、別のコマンドがトリガーされる場合があります。このコマンドは、トランザクションが成功するかどうかに応じて、すべてのトランザクションが完了するかロールバックされるまで、別のイベントをトリガーできます。

次の点を考慮してください。

  • システム内に存在する分散トランザクションの数はいくつですか?
  • 分散トランザクションを処理するアプローチは何ですか? オーケストレーションまたは振り付けを使用して Saga パターンの使用を評価します。
  • 複数のサービスにまたがるトランザクションの数はいくつですか?
  • ACID または BASE トランザクション モデルに従って、データの一貫性と整合性を実現していますか?
  • 複数のサービスにまたがるトランザクションに対して長いチェーン操作を使用していますか?

サービス開発モデルを評価する

マイクロサービス アーキテクチャの最大の利点の 1 つは、テクノロジの多様性です。 マイクロサービスベースのシステムを使用すると、チームは自分達で選択したテクノロジを使用してサービスを開発できます。 従来のアプリケーション開発では、新しいコンポーネントをビルドするときに既存のコードを再利用したり、開発作業を削減するために内部開発フレームワークを作成したりする場合がありました。 複数のテクノロジを使用すると、コードの再利用を妨げる可能性があります。

次の点を考慮します。

  • 新しいサービス開発を促進するためにサービス テンプレートを使用しますか?
  • Twelve-Factor App 方法論に従い、マイクロサービス向けの単一のコード ベースを使用して、依存関係を分離し、構成を外部化していますか?
  • キー コンテナーに機密性の高い構成を保持していますか?
  • サービスをコンテナー化していますか?
  • データの整合性要件を知っていますか?

デプロイ アプローチを評価する

デプロイ アプローチは、さまざまなデプロイ環境でアプリケーションのバージョンをリリースするための方法です。 マイクロサービスベースのシステムは、従来のアプリケーションの場合より迅速にバージョンをリリースする機敏性を提供します。

デプロイ計画を評価する場合は、次の要因を考慮してください。

  • サービスをデプロイするための戦略はありますか?
  • 最新のツールとテクノロジを使用してサービスをデプロイしていますか?
  • サービスをデプロイするときに、チーム間でどのような種類のコラボレーションが必要ですか?
  • Infrastructure as Code (IaC) を使用してインフラストラクチャをプロビジョニングしていますか?
  • デプロイを自動化する DevOps 機能を使用していますか?
  • Twelve-Factor App 方法論によって提案されているとおりに、同じビルドを複数の環境に反映していますか?

ホスティング プラットフォームを評価する

スケーラビリティは、マイクロサービス アーキテクチャの主要なな利点の 1 つです。 これは、マイクロサービスがビジネス ドメインに対応付けられ、各サービスを個別にスケーリングできるからです。 モノリシック アプリケーションは、ホスティング プラットフォーム上に単一のユニットとしてデプロイされ、包括的にスケーリングする必要があります。 その結果、ダウンタイム、デプロイ リスク、メンテナンスが発生します。 モノリシック アプリケーションは、個々のビジネス ドメインに対応するコンポーネントを使用して適切に設計されている場合もあります。 しかし、プロセスの境界が欠落しているため、単一責任の原則に違反する可能性がより高くなります。 これにより、最終的にスパゲティ コードが生成されます。 アプリケーションは単一のホスティング プロセスとして構成およびデプロイされるため、スケーラビリティを確保できません。

マイクロサービスを使用すると、チームはスケーラビリティのニーズをサポートする適切なホスティング プラットフォームを選択できます。 これらの課題に対処するために、自動スケール、エラスティック プロビジョニング、高可用性、デプロイの高速化、簡単な監視など、さまざまなホスティング プラットフォームを利用できます。

次の点を考慮します。

  • サービス (仮想マシン、コンテナー、サーバーレス) のデプロイに使用するホスティング プラットフォームは何ですか?
  • ホスティング プラットフォームはスケーラブルですか? 自動スケールはサポートされていますか?
  • ホスティング プラットフォームのスケーリングにはどのくらいの時間を要しますか?
  • さまざまなホスティング プラットフォームが提供する SLA を理解していますか?
  • ホスティング プラットフォームはディザスター リカバリーをサポートしていますか?

サービスの監視を評価する

監視は、マイクロサービスベースのアプリケーションの重要な要素です。 アプリケーションは個別に実行される多数のサービスに分かれているため、エラーのトラブルシューティングが非常に困難になる場合があります。 適切なセマンティクスを使用してサービスを監視すると、チームはエラーを簡単に監視し、調査して、対応できます。

次の点を考慮します。

  • デプロイされたサービスを監視していますか?
  • ログ メカニズムはありますか? どのようなツールを使用しますか?
  • 分散トレース インフラストラクチャが整っていますか?
  • 例外を記録しますか?
  • 問題を迅速に特定するために、ビジネス エラー コードを維持していますか?
  • サービスに正常性プローブを使用していますか?
  • セマンティック ログを使用しますか? 主要なメトリック、しきい値、およびインジケーターを実装しましたか?
  • ログ中に機密データをマスクしますか?

関連付けトークンの割り当てを評価する

マイクロサービス アーキテクチャでは、アプリケーションは個別にホストされるさまざまなマイクロサービスで構成され、相互にやり取りしてさまざまなビジネスのユースケースに対応します。 アプリケーションが操作を実行するためにバック エンド サービスとやり取りする場合、関連付けトークンと呼ばれる一意の数値を要求に割り当てることができます。 関連付けトークンはエラーのトラブルシューティングに役立つ場合があるため、その使用を検討することをお勧めします。 関連付けトークンは、問題の根本原因の判別、影響の評価、問題の修復方法の決定に役立ちます。

関連付けトークンを使用して、関連付けサービスがどのサービスに含まれ、どのサービスに含まれていないかを特定することで、要求の軌跡を取得できます。 その要求の関連付けトークンを含まないサービスが失敗しました。 失敗した場合は、後でトランザクションを再試行できます。 べき等を適用するには、関連付けトークンを含まないサービスのみで要求を処理します。

たとえば、多くのサービスを含む操作の長いチェーンがあり、トランザクション中にサービスのいずれかが失敗した場合は、関連付けトークンをサービスに渡すと、問題を簡単に調査するために役立ちます。 通常、サービスごとに独自のデータベースがあります。 関連付けトークンはデータベース レコードで保持されます。 トランザクションを再度実行する場合、データベースに特定の関連付けトークンがあるサービスは要求を無視します。 トークンを含まないサービスのみが要求を処理します。

次の点を考慮します。

  • どのステージに関連付けトークンを割り当てますか?
  • どのコンポーネントが関連付けトークンを割り当てますか?
  • 関連付けトークンをサービスのデータベースに保存しますか?
  • 関連付けトークンの形式は何ですか?
  • 関連付けトークンとその他の要求情報をログしますか?

マイクロサービス シャーシ フレームワークの必要性を評価する

マイクロサービス シャーシ フレームワークは、ログ、例外処理、分散トレース、セキュリティ、通信など、横断的な問題に対応する機能を提供する基本フレームワークです。 シャーシ フレームワークを使用する場合は、インフラストラクチャ機能とのやり取りよりも、サービス境界の実装に重点を置く必要があります。

たとえば、カート管理サービスをビルドするとします。 受信トークンを検証し、ログ データベースにログを書き込み、そのサービスのエンドポイントを呼び出して別のサービスと通信する必要があります。 マイクロサービス シャーシ フレームワークを使用すれば、開発作業量を削減できます。 Dapr は、横断的な問題に対処するためのさまざまな構成ブロックを提供する単一のシステムです。

次の点を考慮します。

  • マイクロサービス シャーシ フレームワークを使用しますか?
  • Dapr を使用して横断的な問題についてやり取りしますか?
  • シャーシ フレームワークの言語に非依存ですか?
  • シャーシ フレームワークは汎用的で、あらゆる種類のアプリケーションをサポートしていますか? シャーシ フレームワークには、アプリケーション固有のロジックを含めないでください。
  • シャーシ フレームワークには、必要に応じて選択したコンポーネントまたはサービスを使用するメカニズムが用意されていますか?

アプリケーション テストへのアプローチを評価する

従来、テストは開発が完了し、アプリケーションをユーザー受け入れテスト (UAT) と運用環境にロールアウトする準備が整った後に実施されます。 現在、このアプローチには変更点があり、アプリケーション開発ライフサイクルの早期 (左側) にテストを移行しています。 シフトレフト テストでは、設計、開発、開発後のフェーズを含む、アプリケーション開発ライフサイクルの各フェーズでテストが実施されるため、アプリケーションの品質が向上します。

たとえば、アプリケーションをビルドする場合は、まずアーキテクチャの設計から開始します。 シフトレフト アプローチを使用する場合は、Microsoft Threat Modeling などのツールを使用して、設計の脆弱性をテストします。 開発を開始するときに、静的アプリケーション セキュリティ テスト (SAST) などのツールを実行し、他のアナライザーを使用して問題を明らかにすることで、ソース コードをスキャンできます。 アプリケーションをデプロイした後は、動的アプリケーション セキュリティ テスト (DAST) などのツールを使用して、ホストされている間にテストできます。 機能テスト、カオス テスト、侵入テスト、その他の種類のテストは後で実施します。

次の点を考慮します。

  • 開発ライフサイクル全体をカバーするテスト計画を作成していますか?
  • 要件の会議とアプリケーション開発ライフサイクル全体にテスト担当者を含めますか?
  • テスト駆動設計または振る舞い駆動設計を使用しますか?
  • ユーザー ストーリーをテストしますか? ユーザー ストーリーに受け入れ基準を含めますか?
  • Microsoft Threat Modeling などのツールを使用して設計をテストしますか?
  • 単体テストを作成しますか?
  • 静的コード アナライザーまたはその他のツールを使用してコード品質を測定しますか?
  • 自動化されたツールを使用してアプリケーションをテストしますか?
  • Secure DevOps プラクティスを実装しますか?
  • 統合テスト、エンドツーエンドのアプリケーション テスト、負荷/パフォーマンス テスト、侵入テスト、カオス テストを実施しますか?

マイクロサービスのセキュリティを評価する

サービス保護、セキュリティで保護されたアクセス、セキュリティで保護された通信は、マイクロサービス アーキテクチャの考慮事項の中でも最も重要です。 たとえば、複数のサービスにまたがり、サービスごとにトークン検証を使用するマイクロサービス ベースのシステムは、実行可能なソリューションではありません。 このようなシステムは、システム全体の機敏性と、サービス間で実装ドリフトが発生する可能性に影響を及ぼします。

セキュリティの問題は、通常、API ゲートウェイとアプリケーション ファイアウォールによって処理されます。 ゲートウェイとファイアウォールは、受信要求を受け取り、トークンを検証し、トラフィックをインターセプトするために OWASP Top 10 の原則を実装するなど、さまざまなフィルターとポリシーを適用します。 最後に、要求をバックエンド マイクロサービスに送信します。 この構成は、開発者が、セキュリティに関する横断的な問題ではなく、ビジネスの必要性に専念するために役立ちます。

次の点を考慮します。

  • サービスに認証と認可が必要ですか?
  • API ゲートウェイを使用してトークンと受信要求を検証していますか?
  • SSL または mTLS を使用して、サービス通信のセキュリティを提供していますか?
  • サービス間で必要な通信を許可するために、ネットワーク セキュリティ ポリシーが設定されていますか?
  • 内部および外部通信のセキュリティを提供するために適用できるファイアウォール (L4、L7) を使用していますか?
  • API ゲートウェイでセキュリティ ポリシーを使用してトラフィックを制御していますか?

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Ovais Mehboob Ahmed Khan | シニア クラウド ソリューション アーキテクト - エンジニアリング
  • Nabil Siddiqui | クラウド ソリューション アーキテクト - デジタルとアプリケーションのイノベーション

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ