AWS এবং CDK-এ মাল্টি-টেন্যান্ট অভ্যন্তরীণ পরিষেবাগুলি কীভাবে তৈরি করবেন (পর্ব 1): API গেটওয়ে এবং অ্যাপসিঙ্ক

এই ব্লগ পোস্ট সিরিজে, আমি AWS- এ মাল্টি-টেন্যান্ট পরিষেবা তৈরির জন্য সর্বোত্তম অনুশীলন নিয়ে আলোচনা করতে চাই। মাল্টি-টেন্যান্ট পরিষেবাগুলি কীভাবে তৈরি করা যায় সে সম্পর্কে বিদ্যমান সাহিত্য সাধারণত শত শত গ্রাহকদের (যেমন AWS সার্ভারহীন পরিষেবা ব্যবহার করে একটি মাল্টি-টেন্যান্ট SaaS সলিউশন তৈরি করা ) নিয়ে SaaS অ্যাপ্লিকেশনের লক্ষ্যে থাকে।

এই সিরিজের মূল যুক্তি হল AWS অ্যাকাউন্টে নিয়োজিত কম ক্লায়েন্টের সাথে ব্যবহারের ক্ষেত্রে মাল্টি-টেন্যান্ট পরিষেবা তৈরির উপর ফোকাস করা। সাধারণত, আপনি যখন অভ্যন্তরীণ ব্যবহারের জন্য একটি বহু-ভাড়াটেদার পরিষেবা তৈরি করেন তখন এটি পরিস্থিতিতে প্রযোজ্য হবে।

আমি প্রতিটি ধরনের সার্ভিস-টু-সার্ভিস ইন্টিগ্রেশনের জন্য ব্লগ পোস্টের সিরিজকে তিনটি ভাগে বিভক্ত করব: সিঙ্ক্রোনাস, অ্যাসিঙ্ক্রোনাস এবং ব্যাচ ইন্টিগ্রেশন।

পার্ট 1 দুটি AWS পরিষেবার জন্য মাল্টি-টেন্যান্ট আর্কিটেকচার নিয়ে আলোচনা করবে: API গেটওয়ে এবং অ্যাপসিঙ্ক৷ পুরো নিবন্ধ জুড়ে, আমি টাইপস্ক্রিপ্ট এবং AWS CDK-এ এই নিবন্ধটির জন্য তৈরি নমুনা অ্যাপ্লিকেশন অ্যাপ থেকে কোডটি উল্লেখ করছি: https://github.com/filletofish/aws-cdk-multi-tenant-api-example/tree/main ।

বিষয়বস্তু ওভারভিউ

1. অভ্যন্তরীণ পরিষেবার জন্য মাল্টি-টেনেন্সি

   1.1। ভাড়াটে বিচ্ছিন্নতা

   1.2। মাল্টি ভাড়াটে নিরীক্ষণ

   1.3। স্কেলিং

2. অভ্যন্তরীণ পরিষেবার জন্য মাল্টি-টেনেন্সি

   2.1। ভাড়াটে-বিচ্ছিন্নতা - অ্যাক্সেস-নিয়ন্ত্রণ

   2.2 ভাড়াটে-বিচ্ছিন্নতা - কোলাহলপূর্ণ প্রতিবেশী সমস্যা

   2.3 মাল্টি-টেন্যান্ট পর্যবেক্ষণ

   2.4 মেট্রিক্স, অ্যালার্ম, ড্যাশবোর্ড

   2.5 অনবোর্ডিং এবং অফবোর্ডিং API ক্লায়েন্ট

3. AWS AppSync সহ মাল্টি-টেনেন্সি

4. উপসংহার

1. অভ্যন্তরীণ পরিষেবার জন্য মাল্টি-টেনেন্সি

মাল্টি-টেনেন্সি হল সফ্টওয়্যারটির একক উদাহরণ সহ একাধিক গ্রাহক বা ভাড়াটেদের পরিষেবা দেওয়ার ক্ষমতা।

একবার আপনি একাধিক দলকে আপনার পরিষেবা API কল করার অনুমতি দিলে, আপনার পরিষেবা বহু-ভাড়াটে হয়ে যায়। মাল্টি-টেন্যান্ট আর্কিটেকচার আপনার পরিষেবাগুলিতে অতিরিক্ত জটিলতার পরিচয় দেয়, যেমন টেন্যান্ট আইসোলেশন, টেন্যান্ট-লেভেল মনিটরিং এবং স্কেলিং।

1.1। ভাড়াটে বিচ্ছিন্নতা

সাধারণত, ভাড়াটেদের বিচ্ছিন্নতা নিরাপত্তা উদ্বেগগুলিকে নিশ্চিত করে যে ভাড়াটিয়ারা অন্য ভাড়াটেদের সংস্থানগুলি অ্যাক্সেস করতে বাধা দেয়। এছাড়াও, একজন ভাড়াটে দ্বারা সৃষ্ট কোনো ব্যর্থতা আপনার পরিষেবার অন্যান্য ভাড়াটেদের প্রভাবিত করে না তা নিশ্চিত করার জন্য ভাড়াটে বিচ্ছিন্নতা প্রয়োগ করা হয়। এটি প্রায়ই একটি কোলাহলপূর্ণ প্রতিবেশী সমস্যা হিসাবে উল্লেখ করা হয়। টেন্যান্ট আইসোলেশন কৌশলগুলির উপর AWS হোয়াইটপেপারে আরও দেখুন https://d1.awsstatic.com/whitepapers/saas-tenant-isolation-strategies.pdf ।

1.2। মাল্টি ভাড়াটে নিরীক্ষণ

একবার একাধিক ভাড়াটেরা অবকাঠামোগত সংস্থান ভাগ করা শুরু করলে, আপনার প্রতিটি ভাড়াটেরা কীভাবে আপনার সিস্টেম ব্যবহার করে তা নিরীক্ষণ করতে হবে। এটি সাধারণত বোঝায় যে ভাড়াটে নাম বা শনাক্তকারী আপনার লগ, মেট্রিক্স এবং ড্যাশবোর্ডে উপস্থিত থাকা উচিত। মাল্টি-টেন্যান্ট মনিটরিং বিভিন্ন কারণে কার্যকর হতে পারে:

1. সমস্যা সমাধানের সমস্যা: সমস্যা সনাক্তকরণ এবং সমাধান সহজ করে, ভাড়াটে-নির্দিষ্ট সমস্যাগুলিকে বিস্তৃত থেকে আলাদা করে।
2. সম্পদ বরাদ্দ এবং ক্ষমতা পরিকল্পনা। মাল্টি-টেন্যান্ট মনিটরিং আপনাকে সম্পদ বরাদ্দ এবং ক্ষমতা পরিকল্পনার জন্য প্রতি ভাড়াটে সম্পদ খরচ ট্র্যাক করতে সাহায্য করতে পারে। এমনকি যদি আপনার পরিষেবা সার্ভারহীন হয়, তবুও আপনি শীঘ্রই AWS সীমার মধ্যে কোনটি আঘাত করতে যাচ্ছেন কিনা তা বোঝার জন্য আপনাকে এখনও আপনার ক্লায়েন্ট সংস্থান খরচ বুঝতে হবে (একটি সাধারণ উদাহরণ হল একটি Lambda ফাংশন সমবর্তী এক্সিকিউশন সীমা)।
3. SLA ব্যবস্থাপনা: SLA-এর বিরুদ্ধে ভাড়াটে-নির্দিষ্ট কর্মক্ষমতা ট্র্যাক করার অনুমতি দেয়।
4. বিলিং. এটি অসম্ভাব্য যে আপনি আপনার অভ্যন্তরীণ পরিষেবা ব্যবহার করার জন্য অন্য দলগুলিকে বিল করা শুরু করবেন৷ যাইহোক, কোম্পানির বৃদ্ধির কিছু স্কেলে অন্য দলগুলি পরিষেবার মিতব্যয়ী ব্যবহার নিশ্চিত করার জন্য একটি ভাল ধারণা হতে পারে।

1.3। স্কেলিং

মাল্টি-টেন্যান্ট পরিষেবাগুলি সম্ভবত একক-ভাড়াটেদের পরিষেবাগুলির তুলনায় স্কেলিং চ্যালেঞ্জগুলির মুখোমুখি হয়৷ যাইহোক, স্কেলেবিলিটি একটি বিশাল বিষয় এবং আমি এই ব্লগ পোস্টে এটি কভার করব না।

2. API গেটওয়ে সহ মাল্টি-টেনেন্সি

আপনি যদি AWS-এ REST , HTTP, বা WebSocket API-এর সাথে আপনার AWS ওয়েব পরিষেবা তৈরি করেন তাহলে আপনি সম্ভবত API গেটওয়ে ব্যবহার করছেন।

2.1। ভাড়াটে-বিচ্ছিন্নতা - অ্যাক্সেস-নিয়ন্ত্রণ

পরিষেবার সংস্থান এবং ডেটা, সহজ খরচ-ব্যবস্থাপনা, এবং পরীক্ষা এবং উত্পাদন পরিবেশের মধ্যে পৃথকীকরণের জন্য AWS প্রতিটি পরিষেবাকে তার নিজস্ব AWS অ্যাকাউন্ট(গুলি) এ স্থাপন করার সুপারিশ করে ( একাধিক অ্যাকাউন্ট ব্যবহার করে আপনার AWS পরিবেশ সংগঠিত করা AWS হোয়াইটপেপারে বিশদ দেখুন)।

যদি আপনার কোম্পানির পরিষেবাগুলি AWS-এ মোতায়েন করা হয় তবে আপনার API গেটওয়েতে অ্যাক্সেস পরিচালনা করার সবচেয়ে সুস্পষ্ট সমাধান হল AWS IAM। AWS Cognito হল মাল্টি-টেন্যান্ট API-এ অ্যাক্সেস পরিচালনা করার জন্য আরেকটি বিকল্প ( এপিআই গেটওয়ে ব্যবহার করে একটি টায়ার্ড, মাল্টি-টেন্যান্ট REST API থ্রোটলিং দেখুন, অ্যামাজন কগনিটোর পক্ষে এবং বিরুদ্ধে মামলা )।

AWS IAM এবং AWS কগনিটোর মধ্যে তুলনা একটি পৃথক গভীর-ডাইভের দাবি রাখে। কিন্তু এই নিবন্ধটির জন্য, আমি AWS IAM-এর সাথে লেগে থাকব কারণ আপনার কোম্পানির পরিষেবাগুলি AWS-এ থাকাকালীন অ্যাক্সেস পরিচালনা করার এটি সবচেয়ে সহজ উপায়।

একবার আপনি API গেটওয়ে পদ্ধতির জন্য AWS IAM অনুমোদন সক্ষম করলে ( CFN দেখুন), এই পদ্ধতির জন্য সমস্ত API অনুরোধগুলি আপনার API গেটওয়েতে কল করার অনুমতিপ্রাপ্ত IAM পরিচয়ের শংসাপত্রের সাথে স্বাক্ষর করা উচিত।

ডিফল্টরূপে, AWS অ্যাকাউন্টগুলির মধ্যে কোনও অ্যাক্সেস অনুমোদিত নয়৷ উদাহরণস্বরূপ, অন্য AWS অ্যাকাউন্টের শংসাপত্রের সাথে আপনার API গেটওয়ে আহ্বান করা ব্যর্থ হবে৷ আপনার API এর সাথে আপনার গ্রাহকদের সংহত করতে আপনাকে ক্রস-অ্যাকাউন্ট অ্যাক্সেস সেট আপ করতে হবে। আপনার API গেটওয়েতে ক্রস-অ্যাকাউন্ট অ্যাক্সেস দেওয়ার জন্য আপনি দুটি পদ্ধতি ব্যবহার করতে পারেন: সম্পদ-ভিত্তিক অনুমোদন (এপিআই গেটওয়ে HTTP API-এর জন্য উপলব্ধ নয়) এবং পরিচয়-ভিত্তিক অনুমোদন ( https://repost.aws/knowledge-center/ এ আরও দেখুন অ্যাক্সেস-এপিআই-গেটওয়ে-অ্যাকাউন্ট ):

1. সম্পদ-ভিত্তিক অনুমোদনের সাথে একজন ক্লায়েন্টকে অনবোর্ডিং করা । রিসোর্স-ভিত্তিক অ্যাক্সেসের জন্য, আপনাকে API গেটওয়ে রিসোর্স পলিসি আপডেট করতে হবে এবং আপনার ক্লায়েন্টের AWS অ্যাকাউন্ট যোগ করতে হবে। এই পদ্ধতির প্রধান অসুবিধা হল যে আপনি একবার রিসোর্স পলিসি আপডেট করলে, পরিবর্তনগুলি কার্যকর করার জন্য API গেটওয়ে স্টেজকে পুনরায় স্থাপন করতে হবে (AWS ডক্স [1] এবং [2] দেখুন)। যাইহোক, আপনি যদি CDK ব্যবহার করেন তাহলে আপনি নতুন ধাপের স্থাপনা স্বয়ংক্রিয়ভাবে করতে পারেন ( Api Gateway এর জন্য AWS CDK ডক্স দেখুন)। আরেকটি অসুবিধা হল সম্পদ নীতির সর্বোচ্চ দৈর্ঘ্যের সীমা।

   
   

2. পরিচয়-ভিত্তিক অনুমোদন সহ একজন ক্লায়েন্টকে অনবোর্ডিং করা । পরিচয়-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের জন্য, আপনাকে ক্লায়েন্টের জন্য একটি IAM ভূমিকা তৈরি করতে হবে এবং ভূমিকার সংস্থান নীতি (বিশ্বস্ত সম্পর্ক) আপডেট করে ক্লায়েন্টকে এটি অনুমান করার অনুমতি দিতে হবে। আপনি IAM ব্যবহারকারীদের ব্যবহার করতে পারেন, কিন্তু IAM ভূমিকা নিরাপত্তা দৃষ্টিকোণ থেকে ভাল। ভূমিকাগুলি অস্থায়ী শংসাপত্রগুলির সাথে প্রমাণীকরণের অনুমতি দেয় এবং IAM ব্যবহারকারীর শংসাপত্রগুলি সংরক্ষণ করার প্রয়োজন হয় না৷ অ্যাকাউন্ট প্রতি 1,000 ভূমিকার একটি সীমা আছে, কিন্তু এই সীমা সামঞ্জস্যযোগ্য। এছাড়াও, আপনার API-এ ক্রস-অ্যাকাউন্ট অ্যাক্সেস পাওয়ার জন্য ভূমিকা-ভিত্তিক পদ্ধতির আরেকটি অসুবিধা হল যে আপনাকে প্রতিটি নতুন API ক্লায়েন্টের জন্য একটি IAM ভূমিকা তৈরি করতে হবে। যাইহোক, ভূমিকা ব্যবস্থাপনা CDK দিয়ে স্বয়ংক্রিয় হতে পারে ( প্রদত্ত CDK অ্যাপ থেকে কোড নমুনা দেখুন)।

AWS IAM অনুমোদন আপনাকে শুধুমাত্র API গেটওয়েতে অ্যাক্সেস নিয়ন্ত্রণ করতে দেয় (IAM নীতি ব্যবহার করে আপনি নির্দিষ্ট করতে পারেন যে AWS অ্যাকাউন্ট কোনটিকে API গেটওয়ে এন্ডপয়েন্ট বলতে পারে)। আপনার পরিষেবার ডেটা এবং অন্যান্য অন্তর্নিহিত সংস্থানগুলিতে নিয়ন্ত্রণ অ্যাক্সেস কার্যকর করার দায়িত্ব আপনার। আপনার পরিষেবার মধ্যে, আপনি আরও অ্যাক্সেস নিয়ন্ত্রণের জন্য API গেটওয়ে অনুরোধের সাথে পাস করা কলারের AWS IAM ARN ব্যবহার করতে পারেন:

 export const handler = async (event: APIGatewayEvent, context: Context): Promise<APIGatewayProxyResult> => { // IAM Principal ARN of the api caller const callerArn = event.requestContext.identity.userArn!; // .. business logic based on caller return { statusCode: 200, body: JSON.stringify({ message: `Received API Call from ${callerArn}`, }) }; };

2.2। ভাড়াটে-বিচ্ছিন্নতা — কোলাহলপূর্ণ প্রতিবেশী সমস্যা

ডিফল্ট API গেটওয়ে সীমা হল 10,000 TPS ( API গেটওয়ে কোটা এবং সীমা )। যাইহোক, আপনার ডাউনস্ট্রিম নির্ভরতার কারণে, আপনার পরিষেবার কম TPS সীমা প্রয়োজন হতে পারে। একটি একক ভাড়াটে থেকে API অনুরোধগুলির একটি ওভারলোড এড়াতে যা পুরো সিস্টেমের প্রাপ্যতাকে প্রভাবিত করবে আপনাকে প্রতি-ভাড়াটে API রেট সীমিতকরণ (এটিকে "থ্রটলিং" বা "ভর্তি নিয়ন্ত্রণ"ও বলা হয়) প্রয়োগ করা উচিত।

প্রতিটি ক্লায়েন্টের জন্য আলাদাভাবে সীমা কনফিগার করতে আপনি API গেটওয়ে API ব্যবহারের পরিকল্পনা এবং কী ব্যবহার করতে পারেন (বিশদ বিবরণের জন্য AWS ডকুমেন্টেশন দেখুন [1], [2], এবং [3])

2.3। মাল্টি ভাড়াটে মনিটরিং

API গেটওয়েতে দুটি ধরণের লগ রয়েছে:

1. API গেটওয়ে এক্সিকিউশন লগস: অনুরোধ বা প্রতিক্রিয়া প্যারামিটারের মান, কী কী API কী প্রয়োজন, ব্যবহারের পরিকল্পনাগুলি সক্ষম করা আছে কিনা ইত্যাদির মতো ডেটা রয়েছে। ডিফল্টরূপে সক্রিয় নয়, কিন্তু কনফিগার করা যেতে পারে।

   
   

2. API গেটওয়ে অ্যাক্সেস লগ বৈশিষ্ট্য: আপনার API কে অ্যাক্সেস করেছে, কিভাবে এটি অ্যাক্সেস করা হয়েছে, কোন এন্ডপয়েন্ট অ্যাক্সেস করা হয়েছে এবং API কলের ফলাফল আপনাকে লগ করতে দেয়৷ আপনি আপনার লগ বিন্যাস প্রদান করতে পারেন এবং প্রসঙ্গ ভেরিয়েবলের সাথে কী লগ করবেন তা চয়ন করতে পারেন (সিডিকেতে ডক্স দেখুন)।

আপনার API ক্লায়েন্টদের অনুরোধ নিরীক্ষণ করতে, আমি অ্যাক্সেস লগিং সক্ষম করার সুপারিশ করব। আপনি অন্তত কলারের AWS IAM ARN ( $context.identity.userArn ), অনুরোধের পথ ( $context.path ), আপনার পরিষেবার প্রতিক্রিয়া স্ট্যাটাস কোড $context.status এবং API কল লেটেন্সি ( $context.responseLatency ) লগ করতে পারেন .

ব্যক্তিগতভাবে, গণনা হিসাবে AWS IAM Auth এবং Lambda ফাংশন সহ একটি পরিষেবার জন্য আমি এই API গেটওয়ে অ্যাক্সেস লগিং কনফিগারেশনটিকে দরকারী বলে মনে করেছি:

 const formatObject = { requestId: '$context.requestId', extendedRequestId: '$context.extendedRequestId', apiId: '$context.apiId', resourceId: '$context.resourceId', domainName: '$context.domainName', stage: '$context.stage', path: '$context.path', resourcePath: '$context.resourcePath', httpMethod: '$context.httpMethod', protocol: '$context.protocol', accountId: '$context.identity.accountId', sourceIp: '$context.identity.sourceIp', user: '$context.identity.user', userAgent: '$context.identity.userAgent', userArn: '$context.identity.userArn', caller: '$context.identity.caller', cognitoIdentityId: '$context.identity.cognitoIdentityId', status: '$context.status', integration: { // The status code returned from an integration. For Lambda proxy integrations, this is the status code that your Lambda function code returns. status: '$context.integration.status', // For Lambda proxy integration, the status code returned from AWS Lambda, not from the backend Lambda function code. integrationStatus: '$context.integration.integrationStatus', // The error message returned from an integration // A string that contains an integration error message. error: '$context.integration.error', latency: '$context.integration.latency', }, error: { responseType: '$context.error.responseType', message: '$context.error.message', }, requestTime: '$context.requestTime', responseLength: '$context.responseLength', responseLatency: '$context.responseLatency', }; const accessLogFormatString = JSON.stringify(formatObject); const accessLogFormat = apigw.AccessLogFormat.custom(accessLogFormatString);

একবার লগিং সক্ষম হয়ে গেলে, আপনি ক্লাউডওয়াচ ইনসাইট ব্যবহার করতে পারেন সহজেই একটি নির্বাচিত API ক্লায়েন্ট থেকে সাম্প্রতিক কলগুলি পেতে:

 fields @timestamp, path, status, responseLatency, userArn | sort @timestamp desc | filter userArn like 'payment-service' | limit 20

2.4। মেট্রিক্স, অ্যালার্ম, ড্যাশবোর্ড

ডিফল্টরূপে API গেটওয়ে দ্বারা সমর্থিত CloudWatch মেট্রিক্স সমস্ত অনুরোধের জন্য একত্রিত হয়। কিন্তু আপনি আপনার API-এর ক্লায়েন্ট (ভাড়াটে) ব্যবহার নিরীক্ষণ করতে সক্ষম হওয়ার জন্য আপনার ক্লায়েন্ট নামের একটি অতিরিক্ত মাত্রা সহ কাস্টম ক্লাউডওয়াচ মেট্রিক্স প্রকাশ করতে API গেটওয়ে অ্যাক্সেস লগগুলিকে পার্স করতে পারেন। খুব ন্যূনতম, আমি প্রতি-ক্লায়েন্ট ক্লাউডওয়াচ মেট্রিক্স কাউন্ট, 4xx, 5xx, Dimension=${Client} দ্বারা লেটেন্সি বিভক্ত প্রকাশ করার সুপারিশ করব। আপনি স্ট্যাটাস কোড এবং API পাথের মত মাত্রা যোগ করতে পারেন।

2.4.1। প্রতি-ক্লায়েন্ট মেট্রিক্স প্রকাশের জন্য মেট্রিক লগ ফিল্টার ব্যবহার করা

CloudWatch মেট্রিক লগ ফিল্টার (ডক্স দেখুন) আপনাকে একটি কাস্টম ফিল্টার প্রদান করতে এবং API গেটওয়ে অ্যাক্সেস লগ থেকে মেট্রিক মান বের করার অনুমতি দেয় (নীচে উদাহরণ দেখুন)। মেট্রিক লগ ফিল্টারগুলি লগ থেকে কাস্টম মেট্রিক্সের মাত্রার জন্য মান বের করার অনুমতি দেয়। মাল্টি-টেনেন্সি মনিটরিংয়ের জন্য, ডাইমেনশন ক্লায়েন্ট কলারের IAM ARN হতে পারে।

মেট্রিক লগ ফিল্টারগুলির প্রধান সুবিধাগুলি হল (1) পরিচালনার জন্য কোনও গণনা নেই (2) এটি সহজ এবং সস্তা। কিন্তু আপনি কোনো ডেটা পরিবর্তন করতে পারবেন না (যেমন IAM ARN-এর পরিবর্তে আরও পঠনযোগ্য ক্লায়েন্টের নাম সেট করুন) এবং প্রতি একক লগ গ্রুপে (ডক্স) 100 মেট্রিক ফিল্টারের সীমা রয়েছে।

ডাইমেনশন Client এবং Path সহ Count প্রকাশ করতে ক্লাউডওয়াচ মেট্রিক লগ ফিল্টারের উদাহরণ

 new logs.MetricFilter(this, 'MultiTenantApiCountMetricFilter', { logGroup: accessLogsGroup, filterPattern: logs.FilterPattern.exists('$.userArn'), metricNamespace: metricNamespace, metricName: 'Count', metricValue: '1', unit: cloudwatch.Unit.COUNT, dimensions: { client: '$.userArn', method: '$.httpMethod', path: '$.path',},}); });

প্রদত্ত নমুনা CDK অ্যাপ্লিকেশনে 4xx, 5xx ত্রুটি এবং লেটেন্সি মেট্রিক্সের জন্য সমস্ত মেট্রিক ফিল্টার দেখুন।

2.4.2। প্রতি-ক্লায়েন্ট মেট্রিক্স প্রকাশের জন্য Lambda ফাংশন ব্যবহার করে

বিকল্প বিকল্প হল লগ পার্স করতে, মেট্রিক্স বের করতে এবং সেগুলি প্রকাশ করতে একটি Lambda ফাংশন তৈরি করা। এটি আপনাকে অজানা ক্লায়েন্টকে ফিল্টার করার মতো বা userArn থেকে ক্লায়েন্টের নাম বের করার মতো আরও কাস্টম জিনিস করতে দেয়।

API গেটওয়ে অ্যাক্সেস লগগুলিতে Lambda ফাংশন সাবস্ক্রাইব করতে CDK কোডের মাত্র কয়েকটি লাইন সহ:

 const logProcessingFunction = new lambda.NodejsFunction( this, 'log-processor-function', { functionName: 'multi-tenant-api-log-processor-function', } ); new logs.SubscriptionFilter(this, 'MultiTenantApiLogSubscriptionFilter', { logGroup: accessLogsGroup, destination: new logsd.LambdaDestination(logProcessingFunction), filterPattern: logs.FilterPattern.allEvents(), });

কোডে সম্পূর্ণ উদাহরণের পাশাপাশি লগ প্রসেসর ল্যাম্বডা ফাংশনের বাস্তবায়ন দেখুন।

একবার আপনি ক্লায়েন্ট দ্বারা বিভক্ত API গেটওয়ে মেট্রিক্স প্রকাশ করা শুরু করলে, আপনি এখন প্রতিটি ক্লায়েন্টের জন্য আলাদাভাবে ক্লাউডওয়াচ ড্যাশবোর্ড এবং ক্লাউডওয়াচ অ্যালার্ম তৈরি করতে পারেন।

2.5। অনবোর্ডিং এবং অফবোর্ডিং API ক্লায়েন্ট

আপনার CDK অ্যাপটি ক্লায়েন্টের নাম, তাদের AWS অ্যাকাউন্ট, অনুরোধ করা TPS সীমা এবং অন্যান্য মেটাডেটা সহ একটি কনফিগার সংরক্ষণ করার একটি সহজ সমাধান হতে পারে। একটি নতুন API ক্লায়েন্ট অনবোর্ড করতে আপনাকে কোডে পরিচালিত কনফিগারেশনে এটি যোগ করতে হবে:

 interface ApiClientConfig { name: string; awsAccounts: string[]; rateLimit: number; burstLimit: number; } const apiClients: ApiClientConfig[] = [ { name: 'payment-service', awsAccounts: ['111122223333','444455556666'], rateLimit: 10, burstLimit: 2, }, { name: 'order-service', awsAccounts: ['777788889999'], rateLimit: 1, burstLimit: 1, }, ];

এই কনফিগারেশনটি ব্যবহার করে CDK অ্যাপটি তারপরে একটি IAM ভূমিকা, API গেটওয়ে ইউসেজ কী তৈরি করতে পারে এবং ক্লায়েন্টের নাম Lambda ফাংশনে পাঠাতে পারে যা অ্যাক্সেস লগ পার্স করে (এটি নমুনা অ্যাপ্লিকেশন কোডে দেখুন)।

3. AWS AppSync সহ মাল্টি-টেনেন্সি

আপনার পরিষেবার একটি GraphQL API থাকলে আপনি সম্ভবত AppSync ব্যবহার করেন। একইভাবে API গেটওয়েতে, আপনি AppSync অনুরোধ অনুমোদন করতে IAM Auth ব্যবহার করতে পারেন। AppSync-এর কোনও সংস্থান নীতি নেই ( GH সমস্যা দেখুন), তাই আপনি AppSync API এ অ্যাক্সেস নিয়ন্ত্রণ সেট আপ করার জন্য শুধুমাত্র একটি ভূমিকা-ভিত্তিক অনুমোদন ব্যবহার করতে পারেন। একইভাবে API গেটওয়েতে, আপনি আপনার পরিষেবার প্রতিটি নতুন ভাড়াটে জন্য একটি পৃথক IAM ভূমিকা তৈরি করবেন।

দুর্ভাগ্যবশত, AppSync-এর প্রতি-ক্লায়েন্ট থ্রটলিং-এর জন্য সীমিত সমর্থন রয়েছে যা আমাদের ভাড়াটে বিচ্ছিন্নতা এবং পর্যবেক্ষণের জন্য প্রয়োজন। আপনি যখন WAF এর সাথে AppSync-এর জন্য TPS সীমা সেট আপ করতে পারেন, আপনি আপনার পরিষেবা ভাড়াটেদের বিচ্ছিন্ন করার জন্য পৃথক প্রতি-ক্লায়েন্ট সীমা তৈরি করতে পারবেন না। একইভাবে, AppSync এপিআই গেটওয়ের মতো অ্যাক্সেস লগ প্রদান করে না।

সমাধান? আপনি আপনার AppSync-এ একটি প্রক্সি হিসাবে API গেটওয়ে যোগ করতে পারেন এবং ভাড়াটে বিচ্ছিন্নতা এবং পর্যবেক্ষণের মতো বহু-ভাড়াটি সংক্রান্ত প্রয়োজনীয়তাগুলি বাস্তবায়ন করতে উপরে বর্ণিত সমস্ত API গেটওয়ে বৈশিষ্ট্যগুলি ব্যবহার করতে পারেন৷ এর উপরে, আপনি অন্যান্য API গেটওয়ে বৈশিষ্ট্যগুলি ব্যবহার করতে পারেন যেমন Lambda Authorizers, কাস্টম ডোমেন, এবং API লাইফসাইকেল পরিচালনা যা এখনও AppSync-এ বিদ্যমান নেই। অসুবিধা হল আপনার অনুরোধের জন্য সামান্য অতিরিক্ত বিলম্ব।

4। উপসংহার

এটাই. আপনার যদি কোন প্রশ্ন বা ধারনা থাকে, আমাকে মন্তব্যে জানান বা সরাসরি আমার সাথে যোগাযোগ করুন। এই সিরিজের পরবর্তী অংশে, আমি AWS ইভেন্ট ব্রিজ এবং AWS SQS/SNS এর সাথে অ্যাসিঙ্ক্রোনাস অভ্যন্তরীণ একীকরণের জন্য সেরা অনুশীলনগুলি পর্যালোচনা করব।

আপনি যদি AWS-এর উপরে বহু-ভাড়াটেদার পরিষেবা তৈরির বিষয়ে গভীরভাবে ডুব দিতে চান তবে আমি এই সংস্থানগুলিকে দরকারী বলে মনে করেছি:

1. SaaS টেন্যান্ট আইসোলেশন কৌশলগুলির উপর AWS শ্বেতপত্র
2. মাল্টি-টেন্যান্ট সিস্টেমে ন্যায্যতা
3. AWS re:Invent 2021 — SaaS আর্কিটেকচার প্যাটার্ন: ধারণা থেকে বাস্তবায়ন পর্যন্ত