SSH से REST तक: Slack की EMR डेटा पाइपलाइन का सुरक्षा-केंद्रित आधुनिकीकरण

 (slack.engineering)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Slack के डेटा प्लेटफ़ॉर्म में 700 से अधिक SSH-आधारित Operator दैनिक search indexing, analytics jobs आदि जैसी महत्वपूर्ण डेटा पाइपलाइनों को चलाते थे, और हर job के लिए production AWS EMR cluster में सीधा SSH access चाहिए होता था, जिससे security threat surface बहुत बड़ा हो गया था
  • यह SSH निर्भरता सिर्फ़ security risk नहीं थी, बल्कि Spark on Kubernetes, EMR on EKS migration, और Whitecastle initiative की completion जैसे infrastructure modernization के रास्ते की एक बड़ी बाधा भी थी
  • समाधान के रूप में YARN Distributed Shell का उपयोग किया गया, जिससे YARN container के भीतर arbitrary shell commands भी चलाए जा सके, और Slack के अपने REST gateway Quarry के ज़रिए सभी job submissions को एकीकृत किया गया
  • 8 data regions में zero downtime के साथ 700+ jobs migrate किए गए, और 3 quarters के भीतर 100% SSH removal पूरा हुआ
  • नतीजतन attack surface कम हुआ, job reliability बढ़ी, observability बेहतर हुई, और साथ ही Whitecastle completion तथा Spark on Kubernetes जैसी अगली पीढ़ी की infrastructure initiatives के लिए आधार तैयार हुआ

पृष्ठभूमि: SSH-आधारित डेटा प्लेटफ़ॉर्म कैसे बना

  • लगभग 2017 में बने Slack डेटा प्लेटफ़ॉर्म ने Airflow से EMR cluster पर jobs चलाने के लिए सबसे सीधे रास्ते के रूप में SSH approach अपनाई
    • SSHOperator के ज़रिए EMR master node में login करके spark-submit जैसे commands चलाए जाते थे
  • बाद में अलग-अलग teams ने विभिन्न उपयोगों के लिए—सिर्फ़ Spark नहीं बल्कि MapReduce, AWS CLI, custom Python scripts—अपने custom SSH-based Operators बना लिए
  • परिणामस्वरूप production environment में 700 से अधिक SSH-based jobs जमा हो गए

SSH approach की वास्तविक लागत

  • संभावित security risk

    • compute clusters तक direct SSH access से attack surface बढ़ता है
    • orchestration workers पर keys distribute और rotate करने से operational overhead बढ़ता है
    • granular audit के लिए कई systems के logs को correlate करना पड़ता है
    • dedicated security groups और custom configurations के कारण access management जटिल हो जाता है

  • operational समस्याएँ

    • jobs distribute होने के बजाय EMR master node पर सीधे चलती थीं, जिससे resource contention होता था
    • Kubernetes Pod restart होने पर SSH connection टूटने से jobs fail हो जाती थीं
    • लंबे समय तक चलने वाली jobs connection बंद होने के बाद भी चलती रहती थीं और zombie processes बन जाती थीं
    • connection टूटने पर job सफल हुई या विफल, यह पता नहीं चलता था

  • modernization blockers

    • Spark on Kubernetes और EMR on EKS की ओर बढ़ना संभव नहीं था (पहले SSH dependency हटाना ज़रूरी था)
    • आख़िरी main-account EMR cluster को child account में नहीं ले जाया जा सका, इसलिए Whitecastle initiative अधूरा था
      • Whitecastle, security और network isolation मज़बूत करने के लिए Slack की AWS infrastructure को child accounts में migrate करने की initiative थी
    • सही तरह की job monitoring और observability लागू नहीं की जा सकती थी

  • प्रमुख उदाहरण — Search Infrastructure team

    • terabytes of data से दैनिक Solr search index बनाने वाली pipeline, जो Slack search feature का एक core हिस्सा है
    • SSH-based job submission पर निर्भर होने के कारण यह ऊपर बताई गई सभी reliability समस्याओं से प्रभावित थी

REST-आधारित job submission की बुनियादी अवधारणा

  • SSH की मूल सीमा

    • SSH connection stateful direct connection होता है; Pod restart आदि से connection टूट जाए तो command चलती रह सकती है, fail हो सकती है, या orphan process छूट सकता है
    • reconnect करके state पता करने का कोई भरोसेमंद तरीका नहीं होता

  • REST विकल्प

    • YARN, Trino, Snowflake जैसे आधुनिक compute engines HTTP API के ज़रिए job submission को support करते हैं
      • POST job request → job ID लौटाता है
      • GET job status lookup → running/completed/failed की जानकारी
      • DELETE job → साफ़-सुथरा cancel
    • job lifecycle को server side पर manage किया जाता है; client restart हो जाए तब भी job चलती रहती है और status query किया जा सकता है

  • YARN की भूमिका और सीमा

    • Hadoop workloads (MapReduce, Spark, Hive) में YARN resource manager भी है और REST API भी देता है
    • लेकिन aws s3 sync, hadoop distcp जैसे arbitrary shell commands चलाने वाली 300 से अधिक CLI-based jobs के लिए ready-to-use REST API नहीं था
    • यही समस्या YARN Distributed Shell ने हल की

सफलता की कुंजी: YARN Distributed Shell

  • Spark के लिए Livy REST API और Hive के लिए HiveServer2 होने से migration अपेक्षाकृत आसान था
  • लेकिन MapReduce jobs और 300+ CLI-based jobs के लिए तुरंत इस्तेमाल होने वाला REST API नहीं था, इसलिए यही सबसे बड़ी चुनौती थी

  • आवश्यकताएँ

    • architecture के अनुरूप स्वाभाविक रूप से फिट होने वाला सरल REST-based solution
    • मौजूदा authentication/authorization mechanisms का उपयोग (अलग custom security layer की ज़रूरत नहीं)
    • proprietary solution के बजाय open source protocol (standard YARN API) का उपयोग
    • न्यूनतम complexity के साथ custom job execution infrastructure बनाने और चलाने से बचना

  • जिन विकल्पों पर विचार हुआ लेकिन छोड़ा गया

    • remote command execution के लिए custom wrapper service बनाना
    • Ansible, Salt जैसे remote execution frameworks का उपयोग
    • YARN में बिल्कुल नया job type जोड़ना
    • ये सभी अत्यधिक complexity, custom security implementation, और नई dependencies जैसी समस्याओं के कारण अनुपयुक्त थे

  • YARN Distributed Shell की खोज

    • org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster के ज़रिए YARN container के अंदर arbitrary shell scripts चलाना संभव था
    • यह YARN में पहले से शामिल capability थी, उसी REST API का उपयोग करती थी, और custom security layer की ज़रूरत नहीं थी

  • यह कैसे काम करता है

    • 1. command script को S3 पर upload करें (उदाहरण: aws s3 sync /tmp/data/ s3://bucket/output/)
    • 2. Distributed Shell configuration के साथ YARN में submit करें
      • application-type को MAPREDUCE सेट किया जाता है, और am-container-spec में DISTRIBUTEDSHELLSCRIPTLOCATION, DISTRIBUTEDSHELLSCRIPTLEN, DISTRIBUTEDSHELLSCRIPTTIMESTAMP जैसे environment variables शामिल होते हैं
    • 3. YARN container allocate करता है, script download करता है और execute करता है
      • YARN memory/vCore जैसी resource limits, container isolation, retries और fault tolerance, graceful cancellation, और YARN UI-आधारित logging को manage करता है
  • इस फ़ैसले से सिर्फ़ Hadoop workloads ही नहीं, बल्कि aws s3 sync, hadoop distcp, और custom Python scripts भी YARN containers के अंदर चलाए जा सके

समाधान: Quarry

  • Quarry, EMR/YARN, Trino, Snowflake जैसे कई compute engines पर jobs submit करने के लिए बनाया गया Slack का REST-based job submission gateway है
  • यह पहले से authentication, reliability और observability की समस्याएँ हल कर चुका था, इसलिए SSH हटाने के उद्देश्य से बिल्कुल मेल खाता था

  • Quarry की क्षमताएँ

    • authentication: SSH keys की जगह service-to-service tokens
    • job submission: YARN, Trino, Snowflake को REST API के माध्यम से request भेजना
    • status tracking: job status की server-side monitoring
    • lifecycle management: REST API के ज़रिए graceful cancellation और cleanup
    • observability: सभी job submissions के लिए structured logs, metrics, और tracing

  • architecture में बदलाव

    • पहले: Airflow → SSH Connection → EMR Master Node → Execute Command
    • बाद में: Airflow → Quarry REST API → YARN ResourceManager → EMR Container
    • Airflow Operator अब SSH connection के बजाय Quarry को HTTP request भेजता है; Quarry YARN में submit करता है और status poll करता है
    • Airflow Pod restart होने पर भी jobs बनी रहती हैं, क्योंकि Quarry connection continuity संभालता है

  • Quarry की ताकत

    • YARN Distributed Shell support के कारण यह general-purpose job submission gateway बन गया
    • Spark jobs, Hive queries, और shell scripts—सभी एक ही REST API से submit किए जा सकते थे
    • SSH credentials और clusters तक direct access पूरी तरह हट गया, और अब सिर्फ़ authentication तथा server-side job tracking वाले REST calls इस्तेमाल होते हैं

migration यात्रा

  • 8 अलग-अलग data regions में 700+ production jobs, अलग network configurations, data sovereignty requirements, और search indexing जैसे zero-downtime workloads होने के कारण बहुत व्यवस्थित planning की ज़रूरत थी

  • चरणबद्ध approach

    • Phase 1 – Proof of Concept (PoC): pilot jobs के साथ Quarry-based approach को validate किया गया, पहला Quarry Operator बनाया गया और dev environment में test हुआ
    • Phase 2 – security review: security team के साथ मिलकर credential removal plan तैयार किया गया, और verify किया गया कि REST-based approach security requirements पूरी करती है
    • Phase 3 – OKR-driven execution: इसे Key Result बनाया गया ताकि executive visibility मिले; इसी phase में 80% migration milestone हासिल हुआ
    • Phase 4 – bulk migration: Search Infrastructure, Data Engineering & Analytics, ML Services आदि कई teams ने parallel में बाकी workloads को सभी regions में migrate किया
    • Phase 5 – final cleanup: छूटे हुए DAG पूरे किए गए, सभी legacy SSH Operators हटाए गए, और 100% completion हासिल हुई

  • migration आँकड़े

    • 7 Operator types में 700+ jobs migrate की गईं
    • coordinated rollout के माध्यम से 8 स्वतंत्र data regions में लागू किया गया
    • 5 teams ने नए Operators पर switch किया
    • business-critical services में कोई downtime नहीं हुआ
    • शुरुआती pilot से लेकर 100% SSH removal तक 3 quarters लगे

migration के दौरान सामने आई चुनौतियाँ

  • Challenge 1 — Virtual Memory Check failures

    • data export DAG migration के दौरान, जो jobs SSH पर ठीक चल रही थीं, वे vmem check errors के कारण fail होने लगीं
    • कारण: SSH jobs सीधे master node पर चलती थीं और YARN resource enforcement को bypass कर देती थीं; Quarry jobs को ठीक से YARN में submit करता था, इसलिए virtual memory limit पार करने वाले containers reject हो गए
    • समाधान: AWS best practice के अनुसार सभी clusters में vmem check disable किया गया — "yarn.nodemanager.vmem-check-enabled": "false"
      • यह AWS की उस recommendation के अनुरूप था कि Linux virtual memory accounting विश्वसनीय नहीं है और physical memory limit पर्याप्त होती है
    • सीख: SSH कई समस्याओं को छिपा देता था, इसलिए proper YARN submission पर switch करते समय पहले न दिखने वाली resource limit issues सामने आएँगी, इसका अनुमान रखना चाहिए; dev environment में पर्याप्त testing ज़रूरी है

  • Challenge 2 — network isolation और EKM connectivity problems

    • जब dev search infrastructure jobs को dev cluster से staging analytics cluster पर ले जाया गया, तो EKM (Enterprise Key Management) connection timeout हुआ
    • error: Unable to execute HTTP request: Connect to sts.amazonaws.com:443 failed: connect timed out
    • कारण: original cluster में key management endpoints तक network routing configured थी, लेकिन ज़्यादा सख़्त network segment में मौजूद staging analytics cluster में वही connectivity नहीं थी, जिससे job configuration में explicitly न लिखी गई network topology dependency उजागर हो गई
    • समाधान: search infrastructure workloads को dev ETL cluster में shift किया गया, जहाँ dev services तक routing उपलब्ध थी; जिन workloads को production Hive catalog चाहिए था, उन्हें staging में रखा गया; और dev ETL cluster को scale up करके अतिरिक्त workload संभालने लायक बनाया गया
    • सीख: network topology बेहद महत्वपूर्ण है; किसी cluster पर कौन-सी job चलानी है, यह तय करने से पहले network isolation और account boundaries को समझना ज़रूरी है

  • Challenge 3 — multi-region complexity

    • data sovereignty requirements के कारण 8 स्वतंत्र data regions में EMR clusters चल रहे थे; इसलिए SSH removal असल में 8 parallel migrations जैसा था

    • complexity के पहलू

      • configuration management: हर region के लिए अलग Quarry settings, cluster endpoints, और network routing rules चाहिए थे
      • testing burden: हर code change को सभी 8 regions में validate करना पड़ता था
      • sequential rollout: एक साथ deployment संभव नहीं था, इसलिए region-by-region gradual rollout किया गया
      • region-specific issues: network configurations, data sovereignty rules, और cluster version differences

    • इससे निपटने का तरीका

      • एक pilot region (ज़्यादातर US-based) में validate किया गया
      • region-specific configuration requirements को document किया गया
      • region-aware Quarry Operator बनाया गया
      • gradual rollout और region-by-region learning को अपनाया गया
      • region-wise migration progress को अलग से track किया गया
    • सीख: multi-region infrastructure सिर्फ़ N गुना ज़्यादा काम नहीं होता, बल्कि region-specific failure modes के कारण N गुना ज़्यादा कठिन होता है; cross-region coordination और region-specific debugging के लिए पर्याप्त समय देना चाहिए

परिणाम

  • 100% SSH removal हासिल हुआ, और सभी production jobs Quarry के माध्यम से REST-based submission पर ले जाए गए

  • security उपलब्धियाँ

    • 8 स्वतंत्र data regions के सभी production EMR clusters से SSH access हटा दिया गया, जिससे attack surface काफ़ी कम हुआ
    • SSH key distribution को service-to-service token authentication से replace किया गया, और REST API logging के ज़रिए उचित audit trail मिला
    • सभी job submissions के लिए Quarry के माध्यम से structured logs उपलब्ध हुए
    • आख़िरी AWS main-account EMR cluster को child account में migrate किया गया, जिससे Whitecastle initiative पूरी हुई
    • special security groups और complex permission management हटने से compliance सरल हुआ

  • operational improvements

    • master node resource contention समाप्त हुआ; सभी non-Hadoop jobs अब distributed YARN containers में उचित resource allocation के साथ चलने लगीं
    • client Kubernetes Pod restart होने पर भी jobs जारी रहती हैं, जिससे job reliability में बड़ा सुधार हुआ; zombie processes ख़त्म हुए, और REST API के ज़रिए graceful termination संभव हुई
    • Quarry API ने structured job status/logs/metrics उपलब्ध कराए, जिससे पूरे job lifecycle को track करना, YARN container logs देखना, और सही tools से debugging करना संभव हुआ

  • future foundation

    • SSH dependency हटने से Spark on Kubernetes migration संभव हुआ
    • REST-based architecture cloud-native practices के साथ बेहतर मेल खाती है
    • जटिल SSH setup की तुलना में सरल और maintain करने में आसान Quarry Operator ने teams की onboarding आसान की
    • Airflow को EMR infrastructure details से decouple किया गया
    • सभी job submissions को Quarry पर standardize किया गया, जिससे future changes आसान हो गए
  • completion के बाद 2 साल के production operation ने architecture decision की वैधता साबित की; security, operational stability, और infrastructure flexibility—तीनों में सुधार हुआ

सीखी गई बातें

  • क्या अच्छा काम किया

    • gradual migration: Dev → GovDev/CommDev → Prod क्रमिक rollout और Operator type के हिसाब से migration ने हर चरण से सीख इकट्ठी करने में मदद की
    • मज़बूत team collaboration: Search, Analytics, Data Engineering, ML, Marketing आदि कई क्षेत्रों की teams ने साथ काम किया; तेज़ code review और shared channels में communication मददगार रहे
    • analytics-based progress tracking: सभी regions के migration progress के लिए dashboard बनाया गया, और Airflow database queries से बचे हुए SSH-based tasks पहचाने गए

  • अगर दोबारा करते तो क्या अलग करते

    • network topology को पहले map करना चाहिए था: EKM connectivity जैसी network isolation issues बाद के चरण में दिखीं; Whitecastle account boundaries और network routing को cluster migration से पहले document करना चाहिए था
    • resource limit testing जल्दी करनी चाहिए थी: vmem check issue बाद में सामने आई; शुरुआती pilot phase से ही SSH बनाम YARN resource limit testing शामिल करनी चाहिए थी
    • Operator restrictions पर पहले communication बेहतर होना चाहिए था: अंतिम चरण में जब नए SSHOperator usage को सीमित किया गया, तो कुछ teams को इसकी जानकारी नहीं थी; सभी Airflow users को पहले से व्यापक सूचना देनी चाहिए थी

  • large-scale migration best practices

    • migration से पहले monitoring बनाएँ: बचे हुए कार्यों को हर समय देखने के लिए dashboard शुरू में ही तैयार करें, और Airflow DB queries का उपयोग करें
    • multiple environments में testing: Dev, CommDev, GovDev में test करके environment-specific issues को production से पहले पकड़ें, खासकर account boundaries के पार testing से network isolation issues पहले पकड़ी जा सकती हैं
    • Operator deprecation को gradual रखें: CrunchExecOperator, S3SyncOperator आदि को एक-एक करके retire करें; हर चरण को अपने test और validation के साथ mini-project की तरह चलाएँ—गति थोड़ी कम होगी, लेकिन risk काफ़ी घटेगा

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.