નવી પેઢીના બિલિંગ આર્કિટેક્ચર: ટેરન્ટૂલમાં સંક્રમણ સાથે પરિવર્તન

મેગાફોન જેવા કોર્પોરેશનને બિલિંગમાં ટેરેન્ટૂલની જરૂર કેમ છે? બહારથી એવું લાગે છે કે વિક્રેતા સામાન્ય રીતે આવે છે, કોઈ પ્રકારનું મોટું બૉક્સ લાવે છે, પ્લગને સોકેટમાં પ્લગ કરે છે - અને તે બિલિંગ છે! એક સમયે આવું હતું, પરંતુ હવે તે પ્રાચીન છે, અને આવા ડાયનાસોર પહેલેથી જ લુપ્ત થઈ ગયા છે અથવા લુપ્ત થઈ રહ્યા છે. શરૂઆતમાં, બિલિંગ એ ઇન્વૉઇસ ઇશ્યૂ કરવા માટેની સિસ્ટમ છે - એક ગણતરી મશીન અથવા કેલ્ક્યુલેટર. આધુનિક ટેલિકોમમાં આ છે કરારના નિષ્કર્ષથી સમાપ્તિ સુધી ગ્રાહક સાથેની ક્રિયાપ્રતિક્રિયાના સમગ્ર જીવન ચક્ર માટે ઓટોમેશન સિસ્ટમ, રીઅલ-ટાઇમ બિલિંગ, ચુકવણી સ્વીકૃતિ અને ઘણું બધું સહિત. ટેલિકોમ કંપનીઓમાં બિલિંગ એ લડાયક રોબોટ જેવું છે - મોટા, શક્તિશાળી અને શસ્ત્રોથી ભરેલા.

ટેરન્ટૂલને તેની સાથે શું લેવાદેવા છે? તેઓ તેના વિશે વાત કરશે ઓલેગ ઇવલેવ и આન્દ્રે ન્યાઝેવ. ઓલેગ કંપનીના મુખ્ય આર્કિટેક્ટ છે મેગાફોન વિદેશી કંપનીઓમાં કામ કરવાના બહોળા અનુભવ સાથે, એન્ડ્રી બિઝનેસ સિસ્ટમના ડિરેક્ટર છે. પર તેમના અહેવાલની ટ્રાન્સક્રિપ્ટમાંથી ટેરન્ટૂલ કોન્ફરન્સ 2018 તમે શીખી શકશો કે કોર્પોરેશનોમાં શા માટે આર એન્ડ ડીની જરૂર છે, ટેરેન્ટૂલ શું છે, કંપનીમાં આ ડેટાબેઝના દેખાવ માટે વર્ટિકલ સ્કેલિંગ અને વૈશ્વિકીકરણની મડાગાંઠ કેવી રીતે પૂર્વશરત બની, તકનીકી પડકારો, આર્કિટેક્ચરલ ટ્રાન્સફોર્મેશન અને મેગાફોનનું ટેકનોસ્ટેક નેટફ્લિક્સ જેવું જ કેવી રીતે છે તે વિશે. , Google અને Amazon.

પ્રોજેક્ટ "યુનિફાઇડ બિલિંગ"

પ્રશ્નમાં રહેલા પ્રોજેક્ટને "યુનિફાઇડ બિલિંગ" કહેવામાં આવે છે. તે અહીં હતું કે ટેરન્ટૂલે તેના શ્રેષ્ઠ ગુણો દર્શાવ્યા.

હાઇ-એન્ડ સાધનોની ઉત્પાદકતામાં વૃદ્ધિ સબસ્ક્રાઇબર બેઝની વૃદ્ધિ અને સેવાઓની સંખ્યામાં વૃદ્ધિ સાથે ગતિ જાળવી શકતી નથી; M2M, IoT અને શાખાની વિશેષતાઓને કારણે ગ્રાહકો અને સેવાઓની સંખ્યામાં વધુ વૃદ્ધિની અપેક્ષા હતી. સમય-થી-બજારમાં બગાડ માટે. કંપનીએ 8 વર્તમાન અલગ-અલગ બિલિંગ પ્રણાલીઓને બદલે અનન્ય વિશ્વ-કક્ષાના મોડ્યુલર આર્કિટેક્ચર સાથે એકીકૃત બિઝનેસ સિસ્ટમ બનાવવાનું નક્કી કર્યું.

MegaFon એકમાં આઠ કંપનીઓ છે. 2009 માં, પુનર્ગઠન પૂર્ણ થયું: સમગ્ર રશિયામાં શાખાઓ એક જ કંપની, મેગાફોન ઓજેએસસી (હવે પીજેએસસી) માં ભળી ગઈ. આમ, કંપની પાસે તેમના પોતાના "કસ્ટમ" સોલ્યુશન્સ, શાખા સુવિધાઓ અને વિવિધ સંસ્થાકીય માળખાં, IT અને માર્કેટિંગ સાથે 8 બિલિંગ સિસ્ટમ્સ છે.

જ્યાં સુધી અમારે એક સામાન્ય ફેડરલ પ્રોડક્ટ લોંચ કરવી ન હતી ત્યાં સુધી બધું સારું હતું. અહીં ઘણી મુશ્કેલીઓ ઊભી થઈ: કેટલાક માટે, ટેરિફને ગોળાકાર કરવામાં આવે છે, અન્ય માટે ગોળાકાર નીચે, અને અન્ય માટે - અંકગણિત સરેરાશના આધારે. આવી હજારો ક્ષણો છે.

બિલિંગ સિસ્ટમનું માત્ર એક જ સંસ્કરણ, એક સપ્લાયર હોવા છતાં, સેટિંગ્સ એટલી બધી અલગ થઈ ગઈ કે તેને એકસાથે મૂકવામાં ઘણો સમય લાગ્યો. અમે તેમની સંખ્યા ઘટાડવાનો પ્રયાસ કર્યો, અને બીજી સમસ્યા સામે આવી જે ઘણા કોર્પોરેશનો માટે પરિચિત છે.

વર્ટિકલ સ્કેલિંગ. તે સમયે શાનદાર હાર્ડવેર પણ જરૂરિયાતોને પૂર્ણ કરતા ન હતા. અમે સુપરડોમ હાઇ-એન્ડ લાઇનમાંથી હેવલેટ-પેકાર્ડ સાધનોનો ઉપયોગ કર્યો, પરંતુ તે બે શાખાઓની જરૂરિયાતોને પણ પૂરી કરી શક્યું નહીં. હું મોટા ઓપરેટિંગ ખર્ચ અને મૂડી રોકાણો વિના આડી સ્કેલિંગ ઇચ્છતો હતો.

ગ્રાહકો અને સેવાઓની સંખ્યામાં વૃદ્ધિની અપેક્ષા. સલાહકારો લાંબા સમયથી ટેલિકોમ વિશ્વમાં IoT અને M2M વિશે વાર્તાઓ લાવ્યા છે: સમય આવશે જ્યારે દરેક ફોન અને આયર્ન પાસે સિમ કાર્ડ હશે, અને રેફ્રિજરેટરમાં બે હશે. આજે અમારી પાસે સબ્સ્ક્રાઇબર્સની સંખ્યા છે, પરંતુ નજીકના ભવિષ્યમાં ત્યાં ઘણા વધુ હશે.

તકનીકી પડકારો

આ ચાર કારણોએ અમને ગંભીર ફેરફારો કરવા પ્રેર્યા. સિસ્ટમને અપગ્રેડ કરવા અને શરૂઆતથી ડિઝાઇન કરવા વચ્ચે પસંદગી હતી. અમે લાંબા સમય સુધી વિચાર્યું, ગંભીર નિર્ણયો લીધા, ટેન્ડર રમ્યા. પરિણામે, અમે શરૂઆતથી જ ડિઝાઇન કરવાનું નક્કી કર્યું, અને રસપ્રદ પડકારો - તકનીકી પડકારોનો સામનો કર્યો.

માપનીયતા

જો તે પહેલાં હતું, તો ચાલો કહીએ, ચાલો કહીએ 8 મિલિયન સબ્સ્ક્રાઇબર્સ માટે 15 બિલિંગ, અને હવે તે કામ કરવું જોઈએ 100 મિલિયન સબ્સ્ક્રાઇબર્સ અને વધુ - ભાર વધુ તીવ્રતાનો ક્રમ છે.

અમે Mail.ru અથવા Netflix જેવા મોટા ઈન્ટરનેટ પ્લેયર્સ સાથે સ્કેલમાં તુલનાત્મક બની ગયા છીએ.

પરંતુ લોડ અને સબસ્ક્રાઇબર બેઝ વધારવા માટે આગળની હિલચાલએ અમારા માટે ગંભીર પડકારો ઉભા કર્યા છે.

આપણા વિશાળ દેશની ભૂગોળ

કાલિનિનગ્રાડ અને વ્લાદિવોસ્ટોક વચ્ચે 7500 કિમી અને 10 ટાઇમ ઝોન. પ્રકાશની ગતિ મર્યાદિત છે અને આવા અંતર પર વિલંબ પહેલાથી જ નોંધપાત્ર છે. શાનદાર આધુનિક ઓપ્ટિકલ ચેનલો પર 150 ms એ રીઅલ-ટાઇમ બિલિંગ માટે ખૂબ વધારે છે, ખાસ કરીને કારણ કે તે હવે રશિયામાં ટેલિકોમમાં છે. વધુમાં, તમારે એક વ્યવસાય દિવસમાં અપડેટ કરવાની જરૂર છે, અને વિવિધ સમય ઝોન સાથે આ એક સમસ્યા છે.

અમે ફક્ત સબ્સ્ક્રિપ્શન ફી માટે સેવાઓ પ્રદાન કરતા નથી, અમારી પાસે જટિલ ટેરિફ, પેકેજો અને વિવિધ સંશોધકો છે. અમારે સબ્સ્ક્રાઇબરને માત્ર વાત કરવાની મંજૂરી આપવાની કે નકારવાની જરૂર નથી, પરંતુ તેને ચોક્કસ ક્વોટા આપવાની જરૂર છે - વાસ્તવિક સમયમાં કૉલ્સ અને ક્રિયાઓની ગણતરી કરો જેથી તે ધ્યાન ન આપે.

સહનશીલતા દોષ

આ કેન્દ્રીકરણની બીજી બાજુ છે.

જો આપણે બધા સબ્સ્ક્રાઇબર્સને એક સિસ્ટમમાં એકત્રિત કરીએ છીએ, તો કોઈપણ કટોકટીની ઘટનાઓ અને આપત્તિઓ વ્યવસાય માટે વિનાશક છે. તેથી, અમે સમગ્ર સબસ્ક્રાઇબર બેઝ પર અકસ્માતોની અસરને દૂર કરવા માટે સિસ્ટમને એવી રીતે ડિઝાઇન કરીએ છીએ.

આ ફરીથી વર્ટિકલી સ્કેલ કરવાનો ઇનકારનું પરિણામ છે. જ્યારે અમે આડા સ્કેલ કર્યું, ત્યારે અમે સર્વરની સંખ્યા સેંકડોથી વધારીને હજારો કરી. તેઓનું સંચાલન અને વિનિમયક્ષમ હોવું જરૂરી છે, આઇટી ઇન્ફ્રાસ્ટ્રક્ચરનું આપમેળે બેકઅપ લેવું અને વિતરિત સિસ્ટમને પુનઃસ્થાપિત કરવાની જરૂર છે.

અમે આવા રસપ્રદ પડકારોનો સામનો કર્યો. અમે સિસ્ટમ ડિઝાઇન કરી છે, અને તે સમયે અમે કેવી રીતે વલણમાં છીએ, અમે અદ્યતન તકનીકોને કેટલું અનુસરીએ છીએ તે ચકાસવા માટે અમે વૈશ્વિક શ્રેષ્ઠ પ્રયાસો શોધવાનો પ્રયાસ કર્યો.

વિશ્વનો અનુભવ

આશ્ચર્યજનક રીતે, અમને વૈશ્વિક ટેલિકોમમાં એક પણ સંદર્ભ મળ્યો નથી.

સબ્સ્ક્રાઇબર્સની સંખ્યા અને સ્કેલ, યુએસએ - તેના ટેરિફની સપાટતાના સંદર્ભમાં યુરોપ દૂર થઈ ગયું છે. અમે કેટલાકને ચીનમાં જોયા, અને કેટલાક ભારતમાં મળ્યા અને વોડાફોન ઇન્ડિયાના નિષ્ણાતોને રોક્યા.

આર્કિટેક્ચરનું પૃથ્થકરણ કરવા માટે, અમે IBMની આગેવાની હેઠળ એક ડ્રીમ ટીમ એસેમ્બલ કરી - વિવિધ ક્ષેત્રોના આર્કિટેક્ટ્સ. આ લોકો અમે શું કરી રહ્યા છીએ તેનું પર્યાપ્ત મૂલ્યાંકન કરી શકે છે અને અમારા આર્કિટેક્ચરમાં ચોક્કસ જ્ઞાન લાવી શકે છે.

સ્કેલ

ઉદાહરણ માટે થોડા નંબરો.

અમે સિસ્ટમ ડિઝાઇન કરીએ છીએ એક અબજની અનામત સાથે 80 મિલિયન સબ્સ્ક્રાઇબર્સ. આ રીતે આપણે ભાવિ થ્રેશોલ્ડ દૂર કરીએ છીએ. આ એટલા માટે નથી કારણ કે અમે ચીન પર કબજો કરવા જઈ રહ્યા છીએ, પરંતુ IoT અને M2Mના આક્રમણને કારણે.

300 મિલિયન દસ્તાવેજો વાસ્તવિક સમયમાં પ્રક્રિયા કરવામાં આવે છે. જો કે અમારી પાસે 80 મિલિયન સબ્સ્ક્રાઇબર્સ છે, અમે સંભવિત ક્લાયન્ટ્સ અને જેઓ અમને છોડી ગયા છે જો અમને પ્રાપ્તિપાત્ર એકત્રિત કરવાની જરૂર હોય તો અમે બંને સાથે કામ કરીએ છીએ. તેથી, વાસ્તવિક વોલ્યુમો નોંધપાત્ર રીતે મોટા છે.

2 અબજના વ્યવહારો બેલેન્સ દરરોજ બદલાય છે - આ ચુકવણીઓ, શુલ્ક, કૉલ્સ અને અન્ય ઇવેન્ટ્સ છે. 200 TB ડેટા સક્રિયપણે બદલાઈ રહ્યો છે, થોડો ધીમો બદલો ડેટાનો 8 PB, અને આ એક આર્કાઇવ નથી, પરંતુ એક જ બિલિંગમાં લાઇવ ડેટા છે. ડેટા સેન્ટર દ્વારા સ્કેલ - 5 સાઇટ્સ પર 14 હજાર સર્વર.

ટેકનોલોજી સ્ટેક

જ્યારે અમે આર્કિટેક્ચરનું આયોજન કર્યું અને સિસ્ટમને એસેમ્બલ કરવાનું શરૂ કર્યું, ત્યારે અમે સૌથી રસપ્રદ અને અદ્યતન તકનીકો આયાત કરી. પરિણામ એ ટેક્નોલોજી સ્ટેક છે જે કોઈપણ ઈન્ટરનેટ પ્લેયર અને કોર્પોરેશનોને પરિચિત છે જે હાઈ-લોડ સિસ્ટમ્સ બનાવે છે.

આ સ્ટેક અન્ય મુખ્ય ખેલાડીઓના સ્ટેક્સ જેવું જ છે: Netflix, Twitter, Viber. તે 6 ઘટકો ધરાવે છે, પરંતુ અમે તેને ટૂંકાવીને એકીકૃત કરવા માંગીએ છીએ.

લવચીકતા સારી છે, પરંતુ મોટા કોર્પોરેશનમાં એકીકરણ વિના કોઈ રસ્તો નથી.

અમે એ જ ઓરેકલને ટેરન્ટૂલમાં બદલવાના નથી. મોટી કંપનીઓની વાસ્તવિકતાઓમાં, આ એક યુટોપિયા છે, અથવા અસ્પષ્ટ પરિણામ સાથે 5-10 વર્ષ માટે ધર્મયુદ્ધ છે. પરંતુ Cassandra અને Couchbase ને ટેરેન્ટૂલ સાથે સરળતાથી બદલી શકાય છે, અને તે માટે અમે પ્રયત્નશીલ છીએ.

શા માટે ટેરન્ટૂલ?

અમે આ ડેટાબેઝ શા માટે પસંદ કર્યો તે 4 સરળ માપદંડો છે.

ઝડપ. અમે MegaFon ઔદ્યોગિક સિસ્ટમો પર લોડ પરીક્ષણો હાથ ધર્યા. ટેરન્ટૂલ જીત્યું - તેણે શ્રેષ્ઠ પ્રદર્શન દર્શાવ્યું.

આનો અર્થ એ નથી કે અન્ય સિસ્ટમ્સ MegaFon ની જરૂરિયાતોને પૂરી કરતી નથી. વર્તમાન મેમરી સોલ્યુશન્સ એટલા ઉત્પાદક છે કે કંપનીના અનામત પર્યાપ્ત કરતાં વધુ છે. પરંતુ અમને એવા નેતા સાથે વ્યવહાર કરવામાં રસ છે, અને એવી કોઈ વ્યક્તિ સાથે નહીં જે પાછળ રહે છે, જેમાં લોડ ટેસ્ટનો સમાવેશ થાય છે.

ટેરન્ટૂલ લાંબા ગાળામાં પણ કંપનીની જરૂરિયાતોને આવરી લે છે.

TCO ખર્ચ. MegaFon વોલ્યુમો પર Couchbase માટેના સમર્થન માટે ખગોળશાસ્ત્રીય પ્રમાણમાં નાણાનો ખર્ચ થાય છે, પરંતુ Tarantool સાથે પરિસ્થિતિ વધુ સુખદ છે, અને તે કાર્યક્ષમતામાં સમાન છે.

અન્ય એક સરસ સુવિધા કે જેણે અમારી પસંદગીને સહેજ પ્રભાવિત કરી તે એ છે કે ટેરન્ટૂલ અન્ય ડેટાબેસેસ કરતાં મેમરી સાથે વધુ સારી રીતે કાર્ય કરે છે. તે બતાવે છે મહત્તમ કાર્યક્ષમતા.

વિશ્વસનીયતા. MegaFon વિશ્વસનીયતામાં રોકાણ કરે છે, કદાચ અન્ય કરતાં વધુ. તેથી જ્યારે અમે ટેરન્ટૂલને જોયું, ત્યારે અમને સમજાયું કે અમારે તેને અમારી જરૂરિયાતો પૂરી કરવી પડશે.

અમે અમારો સમય અને નાણાંનું રોકાણ કર્યું, અને Mail.ru સાથે મળીને અમે એન્ટરપ્રાઇઝ વર્ઝન બનાવ્યું, જેનો ઉપયોગ હવે ઘણી અન્ય કંપનીઓમાં થાય છે.

ટેરન્ટૂલ-એન્ટરપ્રાઇઝે સુરક્ષા, વિશ્વસનીયતા અને લોગિંગની દ્રષ્ટિએ અમને સંપૂર્ણપણે સંતુષ્ટ કર્યા છે.

ભાગીદારી

મારા માટે સૌથી મહત્વની બાબત છે વિકાસકર્તા સાથે સીધો સંપર્ક. ટેરન્ટૂલના શખ્સે આ જ લાંચ આપી હતી.

જો તમે કોઈ ખેલાડી પાસે આવો છો, ખાસ કરીને જે એન્કર ક્લાયન્ટ સાથે કામ કરે છે, અને કહે છે કે તમારે આ, આ અને આ કરવા માટે સક્ષમ થવા માટે ડેટાબેઝની જરૂર છે, તો તે સામાન્ય રીતે જવાબ આપે છે:

- ઠીક છે, જરૂરિયાતોને તે ખૂંટોના તળિયે મૂકો - કોઈ દિવસ, અમે કદાચ તેમના સુધી પહોંચીશું.

ઘણા લોકો પાસે આગામી 2-3 વર્ષનો રોડમેપ છે, અને ત્યાં એકીકૃત થવું લગભગ અશક્ય છે, પરંતુ ટેરેન્ટૂલ ડેવલપર્સ તેમની નિખાલસતાથી મોહિત કરે છે, અને માત્ર MegaFonથી જ નહીં, અને તેમની સિસ્ટમને ગ્રાહક માટે અનુકૂળ કરે છે. તે સરસ છે અને અમને ખરેખર તે ગમે છે.

જ્યાં અમે ટેરનટૂલનો ઉપયોગ કર્યો હતો

અમે ટેરેન્ટૂલનો ઉપયોગ કેટલાક ઘટકોમાં કરીએ છીએ. પ્રથમ એક પાઇલટમાં છે, જે અમે એડ્રેસ ડિરેક્ટરી સિસ્ટમ પર બનાવેલ છે. એક સમયે હું ઇચ્છતો હતો કે તે એવી સિસ્ટમ હોય જે Yandex.Maps અને Google Maps જેવી હોય, પરંતુ તે થોડી અલગ રીતે બહાર આવ્યું.

ઉદાહરણ તરીકે, વેચાણ ઈન્ટરફેસમાં સરનામું સૂચિ. ઓરેકલ પર, ઇચ્છિત સરનામું શોધવામાં 12-13 સેકન્ડ લાગે છે. - અસ્વસ્થતા નંબરો. જ્યારે અમે Tarantool પર સ્વિચ કરીએ છીએ, Oracle ને કન્સોલમાં બીજા ડેટાબેઝ સાથે બદલીએ છીએ અને તે જ શોધ કરીએ છીએ, ત્યારે અમને 200x સ્પીડઅપ મળે છે! શહેર ત્રીજા અક્ષર પછી પોપ અપ. હવે અમે ઇન્ટરફેસને અનુકૂલિત કરી રહ્યા છીએ જેથી આ પ્રથમ પછી થાય. જો કે, પ્રતિસાદ ઝડપ સંપૂર્ણપણે અલગ છે - સેકંડને બદલે મિલિસેકન્ડ.

બીજી એપ્લિકેશન એક ટ્રેન્ડી થીમ છે જેને ટુ-સ્પીડ આઇટી કહેવાય છે. કારણ કે દરેક ખૂણેથી સલાહકારો કહે છે કે કોર્પોરેશનોએ ત્યાં જવું જોઈએ.

એક ઇન્ફ્રાસ્ટ્રક્ચર લેયર છે, તેની ઉપર ડોમેન્સ છે, ઉદાહરણ તરીકે, બિલિંગ સિસ્ટમ જેવી કે ટેલિકોમ, કોર્પોરેટ સિસ્ટમ્સ, કોર્પોરેટ રિપોર્ટિંગ. આ તે કોર છે જેને સ્પર્શ કરવાની જરૂર નથી. તે, અલબત્ત, શક્ય છે, પરંતુ પેરાનોઇડલી ગુણવત્તાની ખાતરી કરવી, કારણ કે તે કોર્પોરેશનને પૈસા લાવે છે.

આગળ માઇક્રોસર્વિસિસનું સ્તર આવે છે - જે ઓપરેટર અથવા અન્ય પ્લેયરને અલગ પાડે છે. ચોક્કસ કેશના આધારે માઇક્રોસર્વિસિસ ઝડપથી બનાવી શકાય છે, ત્યાં વિવિધ ડોમેન્સમાંથી ડેટા લાવી શકાય છે. અહીં પ્રયોગો માટેનું ક્ષેત્ર - જો કંઈક કામ ન કરે, તો મેં એક માઇક્રોસર્વિસ બંધ કરી અને બીજી ખોલી. આનાથી માર્કેટ ટુ માર્કેટમાં ખરેખર વધારો થાય છે અને કંપનીની વિશ્વસનીયતા અને ઝડપ વધે છે.

મેગાફોન ખાતે ટેરેન્ટૂલની મુખ્ય ભૂમિકા કદાચ માઇક્રોસર્વિસિસ છે.

જ્યાં અમે ટેરન્ટૂલનો ઉપયોગ કરવાની યોજના બનાવીએ છીએ

જો આપણે અમારા સફળ બિલિંગ પ્રોજેક્ટની તુલના ડોઇશ ટેલિકોમ, સ્વ્યાઝકોમ, વોડાફોન ઇન્ડિયાના ટ્રાન્સફોર્મેશન પ્રોગ્રામ્સ સાથે કરીએ, તો તે આશ્ચર્યજનક રીતે ગતિશીલ અને સર્જનાત્મક છે. આ પ્રોજેક્ટના અમલીકરણની પ્રક્રિયામાં, માત્ર MegaFon અને તેનું માળખું જ રૂપાંતરિત થયું ન હતું, પણ Mail.ru પર Tarantool-enterprise પણ દેખાયા હતા, અને અમારા વિક્રેતા Nexign (અગાઉ પીટર-સર્વિસ) - BSS Box (એક બોક્સવાળી બિલિંગ સોલ્યુશન).

આ, એક અર્થમાં, રશિયન બજાર માટે એક ઐતિહાસિક પ્રોજેક્ટ છે. તેની સરખામણી ફ્રેડરિક બ્રૂક્સના પુસ્તક "ધ પૌરાણિક માનવ-મહિનો" માં વર્ણવેલ સાથે કરી શકાય છે. પછી, 60ના દાયકામાં, IBM એ મેઇનફ્રેમ્સ માટે નવી OS/360 ઓપરેટિંગ સિસ્ટમ વિકસાવવા માટે 5 લોકોને હાયર કર્યા. અમારી પાસે ઓછા છે - 000, પરંતુ અમારી પાસે વેસ્ટ છે, અને ઓપન સોર્સ અને નવા અભિગમોના ઉપયોગને ધ્યાનમાં રાખીને, અમે વધુ ઉત્પાદક રીતે કામ કરીએ છીએ.

નીચે બિલિંગના ડોમેન્સ અથવા, વધુ વ્યાપક રીતે કહીએ તો, બિઝનેસ સિસ્ટમ્સ છે. એન્ટરપ્રાઇઝના લોકો CRMને સારી રીતે જાણે છે. દરેક વ્યક્તિ પાસે પહેલેથી જ અન્ય સિસ્ટમ્સ હોવી જોઈએ: ઓપન API, API ગેટવે.

ઓપન એપીઆઇ

ચાલો ફરીથી નંબરો જોઈએ અને ઓપન API હાલમાં કેવી રીતે કાર્ય કરે છે. તેનો ભાર છે પ્રતિ સેકન્ડ 10 વ્યવહારો. અમે માઇક્રોસર્વિસીસ લેયરને સક્રિયપણે વિકસાવવાની અને MegaFon પબ્લિક API બનાવવાની યોજના બનાવી હોવાથી, અમે આ ભાગમાં ભવિષ્યમાં વધુ વૃદ્ધિની અપેક્ષા રાખીએ છીએ. ત્યાં ચોક્કસપણે 100 વ્યવહારો હશે.

મને ખબર નથી કે આપણે SSO માં Mail.ru સાથે સરખામણી કરી શકીએ કે કેમ - ગાય્સ પાસે પ્રતિ સેકન્ડ 1 વ્યવહારો હોય તેવું લાગે છે. તેમનો ઉકેલ અમારા માટે અત્યંત રસપ્રદ છે અને અમે તેમના અનુભવને અપનાવવાની યોજના બનાવીએ છીએ - ઉદાહરણ તરીકે, Tarantool નો ઉપયોગ કરીને કાર્યાત્મક SSO બેકઅપ બનાવવું. હવે Mail.ru ના વિકાસકર્તાઓ અમારા માટે આ કરી રહ્યા છે.

સીઆરએમ

CRM એ જ 80 મિલિયન સબ્સ્ક્રાઇબર્સ છે જેને અમે એક અબજ સુધી વધારવા માંગીએ છીએ, કારણ કે ત્યાં પહેલેથી જ 300 મિલિયન દસ્તાવેજો છે જેમાં ત્રણ વર્ષના ઇતિહાસનો સમાવેશ થાય છે. અમે ખરેખર નવી સેવાઓની રાહ જોઈ રહ્યા છીએ અને અહીં વૃદ્ધિ બિંદુ જોડાયેલ સેવાઓ છે. આ એક બોલ છે જે વધશે, કારણ કે ત્યાં વધુ અને વધુ સેવાઓ હશે. તદનુસાર, અમને એક વાર્તાની જરૂર પડશે; અમે આમાં ઠોકર ખાવા માંગતા નથી.

ઇન્વૉઇસ ઇશ્યૂ કરવાના સંદર્ભમાં પોતે બિલિંગ, ગ્રાહક એકાઉન્ટ્સ પ્રાપ્ત કરવા સાથે કામ કરવું એક અલગ ડોમેનમાં રૂપાંતરિત. પ્રદર્શન સુધારવા માટે, લાગુ કરેલ ડોમેન આર્કિટેક્ચર આર્કિટેક્ચરલ પેટર્ન.

સિસ્ટમને ડોમેન્સમાં વિભાજિત કરવામાં આવે છે, લોડનું વિતરણ કરવામાં આવે છે અને ખામી સહનશીલતા સુનિશ્ચિત કરવામાં આવે છે. વધુમાં, અમે વિતરિત આર્કિટેક્ચર સાથે કામ કર્યું.

બાકીનું બધું એન્ટરપ્રાઇઝ-લેવલ સોલ્યુશન્સ છે. કોલ સ્ટોરેજમાં - દરરોજ 2 અબજદર મહિને 60 અબજ. કેટલીકવાર તમારે તેમને એક મહિનામાં ગણતરી કરવી પડે છે, અને તે ઝડપથી વધુ સારું છે. નાણાકીય દેખરેખ - આ બરાબર એ જ 300 મિલિયન છે જે સતત વધી રહ્યા છે અને વધી રહ્યા છે: સબ્સ્ક્રાઇબર્સ ઘણીવાર ઓપરેટરો વચ્ચે દોડે છે, આ ભાગને વધારીને.

મોબાઈલ કોમ્યુનિકેશનનો સૌથી ટેલિકોમ ઘટક છે ઑનલાઇન બિલિંગ. આ એવી સિસ્ટમ્સ છે જે તમને કૉલ કરવા અથવા કૉલ ન કરવા, વાસ્તવિક સમયમાં નિર્ણય લેવાની મંજૂરી આપે છે. અહીં લોડ પ્રતિ સેકન્ડ 30 વ્યવહારો છે, પરંતુ ડેટા ટ્રાન્સફરમાં વૃદ્ધિને ધ્યાનમાં રાખીને, અમે યોજના બનાવીએ છીએ 250 વ્યવહારો, અને તેથી અમને ટેરન્ટૂલમાં ખૂબ જ રસ છે.

અગાઉનું ચિત્ર એ ડોમેન્સ છે જ્યાં આપણે ટેરેન્ટૂલનો ઉપયોગ કરવા જઈ રહ્યા છીએ. CRM પોતે, અલબત્ત, વ્યાપક છે અને અમે તેનો ઉપયોગ મૂળમાં જ કરવાના છીએ.

100 મિલિયન સબ્સ્ક્રાઇબરોનો અમારો અંદાજિત TTX આંકડો મને આર્કિટેક્ટ તરીકે મૂંઝવણમાં મૂકે છે - જો 101 મિલિયન હોય તો શું? શું તમારે બધું ફરીથી કરવું પડશે? આને થતું અટકાવવા માટે, અમે કૅશનો ઉપયોગ કરીએ છીએ, તે જ સમયે ઍક્સેસિબિલિટી વધારીએ છીએ.

સામાન્ય રીતે, ટેરન્ટૂલનો ઉપયોગ કરવા માટે બે અભિગમો છે. પ્રથમ - માઇક્રોસર્વિસ સ્તરે તમામ કેશ બનાવો. જ્યાં સુધી હું સમજું છું, VimpelCom આ પાથને અનુસરી રહી છે, ક્લાયંટની કેશ બનાવી રહી છે.

અમે વિક્રેતાઓ પર ઓછા નિર્ભર છીએ, અમે BSS કોર બદલી રહ્યા છીએ, તેથી અમારી પાસે બોક્સની બહાર એક ક્લાયન્ટ ફાઇલ છે. પરંતુ અમે તેને વિસ્તારવા માંગીએ છીએ. તેથી, અમે થોડો અલગ અભિગમ અપનાવીએ છીએ - સિસ્ટમની અંદર કેશ બનાવો.

આ રીતે ત્યાં ઓછું સિંક્રનાઇઝેશન છે - એક સિસ્ટમ કેશ અને મુખ્ય મુખ્ય સ્ત્રોત બંને માટે જવાબદાર છે.

ટ્રાંઝેક્શનલ હાડપિંજર સાથે ટેરેન્ટૂલ અભિગમ સાથે પદ્ધતિ સારી રીતે બંધબેસે છે, જ્યારે ફક્ત અપડેટ્સ સાથે સંબંધિત ભાગો, એટલે કે, ડેટા ફેરફારો, અપડેટ કરવામાં આવે છે. બાકીનું બધું બીજે ક્યાંક સંગ્રહિત કરી શકાય છે. ત્યાં કોઈ વિશાળ ડેટા લેક, અવ્યવસ્થિત વૈશ્વિક કેશ નથી. કેશ સિસ્ટમ માટે, અથવા ઉત્પાદનો માટે, અથવા ગ્રાહકો માટે, અથવા જાળવણી માટે જીવન સરળ બનાવવા માટે રચાયેલ છે. જ્યારે સબ્સ્ક્રાઇબર કૉલ કરે છે અને તમારી સેવાની ગુણવત્તા વિશે નારાજ હોય ​​છે, ત્યારે તમે ગુણવત્તાયુક્ત સેવા પ્રદાન કરવા માંગો છો.

RTO અને RPO

આઇટીમાં બે શબ્દો છે - આરટીઓ и RPO.

પુનઃપ્રાપ્તિ સમય ઉદ્દેશ નિષ્ફળતા પછી સેવાને પુનઃસ્થાપિત કરવામાં જે સમય લાગે છે. RTO = 0 એટલે કે કંઈક નિષ્ફળ જાય તો પણ સેવા ચાલુ રહે છે.

પુનઃપ્રાપ્તિ બિંદુ ઉદ્દેશ - આ ડેટા પુનઃપ્રાપ્તિ સમય છે, ચોક્કસ સમયગાળામાં આપણે કેટલો ડેટા ગુમાવી શકીએ છીએ. RPO = 0 એટલે કે અમે ડેટા ગુમાવતા નથી.

ટેરન્ટૂલ કાર્ય

ચાલો ટેરેન્ટૂલ માટે સમસ્યા હલ કરવાનો પ્રયાસ કરીએ.

આપેલ: એપ્લિકેશન્સની ટોપલી કે જે દરેક વ્યક્તિ સમજે છે, ઉદાહરણ તરીકે, એમેઝોનમાં અથવા બીજે ક્યાંક. જરૂરી છે જેથી શોપિંગ કાર્ટ અઠવાડિયાના 24 દિવસ અથવા 7% સમય 99,99 કલાક કામ કરે. અમને જે ઓર્ડર આવે છે તે ક્રમમાં રહેવા જોઈએ, કારણ કે અમે સબ્સ્ક્રાઇબરનું કનેક્શન રેન્ડમલી ચાલુ અથવા બંધ કરી શકતા નથી - બધું સખત સુસંગત હોવું જોઈએ. પહેલાનું સબ્સ્ક્રિપ્શન આગલાને અસર કરે છે, તેથી ડેટા મહત્વપૂર્ણ છે - કંઈપણ ખૂટવું જોઈએ નહીં.

નિર્ણય. તમે તેને હેડ-ઓન હલ કરવાનો પ્રયાસ કરી શકો છો અને ડેટાબેઝ ડેવલપર્સને પૂછી શકો છો, પરંતુ સમસ્યા ગાણિતિક રીતે ઉકેલી શકાતી નથી. તમે પ્રમેય, સંરક્ષણ કાયદા, ક્વોન્ટમ ભૌતિકશાસ્ત્ર યાદ રાખી શકો છો, પરંતુ શા માટે - તે DB સ્તરે ઉકેલી શકાતું નથી.

સારો જૂનો આર્કિટેક્ચરલ અભિગમ અહીં કામ કરે છે - તમારે વિષય વિસ્તારને સારી રીતે જાણવાની અને આ કોયડાને ઉકેલવા માટે તેનો ઉપયોગ કરવાની જરૂર છે.

અમારું સોલ્યુશન: ટેરન્ટૂલ પર એપ્લિકેશનની વિતરિત રજિસ્ટ્રી બનાવવી - એક ભૂ-વિતરિત ક્લસ્ટર. આકૃતિમાં, આ ત્રણ અલગ-અલગ ડેટા પ્રોસેસિંગ કેન્દ્રો છે - બે યુરલ્સ પહેલાં, એક યુરલ્સની બહાર, અને અમે આ કેન્દ્રો વચ્ચે તમામ વિનંતીઓનું વિતરણ કરીએ છીએ.

Netflix, જે હવે IT માં અગ્રણી ગણાય છે, તેની પાસે 2012 સુધી માત્ર એક ડેટા સેન્ટર હતું. કેથોલિક ક્રિસમસની પૂર્વસંધ્યાએ, 24 ડિસેમ્બર, આ ડેટા સેન્ટર બંધ થઈ ગયું. કેનેડા અને યુએસએના વપરાશકર્તાઓ તેમની મનપસંદ ફિલ્મો વિના છોડી દેવામાં આવ્યા હતા, ખૂબ જ અસ્વસ્થ હતા અને સોશિયલ નેટવર્ક પર તેના વિશે લખ્યું હતું. Netflix પાસે હવે પશ્ચિમ-પૂર્વ કિનારે ત્રણ અને પશ્ચિમ યુરોપમાં એક ડેટા સેન્ટર છે.

અમે શરૂઆતમાં જિયો-ડિસ્ટ્રીબ્યુટેડ સોલ્યુશન બનાવી રહ્યા છીએ - દોષ સહિષ્ણુતા અમારા માટે મહત્વપૂર્ણ છે.

તો આપણી પાસે એક ક્લસ્ટર છે, પરંતુ RPO = 0 અને RTO = 0 વિશે શું? ઉકેલ સરળ છે, વિષય પર આધાર રાખીને.

એપ્લિકેશનમાં શું મહત્વનું છે? બે ભાગો: બાસ્કેટ ફેંકવું માટે ખરીદીનો નિર્ણય લેવો, અને પછી. ટેલિકોમમાં DO ભાગને સામાન્ય રીતે કહેવામાં આવે છે ઓર્ડર કેપ્ચર અથવા ઓર્ડર વાટાઘાટ. ટેલિકોમમાં, ઓનલાઈન સ્ટોર કરતાં આ ઘણું મુશ્કેલ હોઈ શકે છે, કારણ કે ત્યાં ક્લાયંટને સેવા આપવી જોઈએ, 5 વિકલ્પો ઓફર કરવામાં આવે છે, અને આ બધું થોડા સમય માટે થાય છે, પરંતુ ટોપલી ભરાઈ જાય છે. આ ક્ષણે, નિષ્ફળતા શક્ય છે, પરંતુ તે ડરામણી નથી, કારણ કે તે માનવ દેખરેખ હેઠળ ક્રિયાપ્રતિક્રિયાથી થાય છે.

જો મોસ્કો ડેટા સેન્ટર અચાનક નિષ્ફળ જાય, તો પછી આપમેળે બીજા ડેટા સેન્ટર પર સ્વિચ કરીને, અમે કામ કરવાનું ચાલુ રાખીશું. સૈદ્ધાંતિક રીતે, કાર્ટમાં એક ઉત્પાદન ખોવાઈ શકે છે, પરંતુ તમે તેને જોશો, ફરીથી કાર્ટમાં ઉમેરો અને કામ કરવાનું ચાલુ રાખો. આ કિસ્સામાં RTO = 0.

તે જ ક્ષણે, બીજો વિકલ્પ છે: જ્યારે આપણે "સબમિટ કરો" પર ક્લિક કરીએ છીએ, ત્યારે અમે ઈચ્છીએ છીએ કે ડેટા ખોવાઈ ન જાય. આ ક્ષણથી, ઓટોમેશન કામ કરવાનું શરૂ કરે છે - આ RPO = 0 છે. આ બે અલગ-અલગ પેટર્નનો ઉપયોગ કરીને, એક કિસ્સામાં તે ફક્ત એક સ્વિચ કરી શકાય તેવા માસ્ટર સાથે જીઓ-વિતરિત ક્લસ્ટર હોઈ શકે છે, બીજા કિસ્સામાં અમુક પ્રકારના કોરમ રેકોર્ડ. પેટર્ન અલગ અલગ હોઈ શકે છે, પરંતુ અમે સમસ્યા હલ કરીએ છીએ.

વધુમાં, એપ્લિકેશનોની વિતરિત રજિસ્ટ્રી હોવાને કારણે, અમે તે બધાને પણ માપી શકીએ છીએ - ઘણા ડિસ્પેચર્સ અને એક્ઝિક્યુટર્સ છે જેઓ આ રજિસ્ટ્રીને ઍક્સેસ કરે છે.

કેસાન્ડ્રા અને ટેરન્ટૂલ સાથે

બીજો કિસ્સો છે - "બેલેન્સનું પ્રદર્શન". અહીં Cassandra અને Tarantool ના સંયુક્ત ઉપયોગનો એક રસપ્રદ કિસ્સો છે.

અમે Cassandra નો ઉપયોગ કરીએ છીએ કારણ કે દરરોજ 2 બિલિયન કૉલ્સ મર્યાદા નથી, અને વધુ હશે. માર્કેટર્સને સ્રોત દ્વારા ટ્રાફિકને રંગીન કરવાનું પસંદ છે; ઉદાહરણ તરીકે, સામાજિક નેટવર્ક્સ પર વધુ અને વધુ વિગતો દેખાઈ રહી છે. તે બધું વાર્તામાં ઉમેરે છે.

કસાન્ડ્રા તમને કોઈપણ કદમાં આડા સ્કેલ કરવાની મંજૂરી આપે છે.

અમે કસાન્ડ્રા સાથે આરામદાયક અનુભવીએ છીએ, પરંતુ તેની એક સમસ્યા છે - તે વાંચવામાં સારી નથી. રેકોર્ડિંગ પર બધું બરાબર છે, 30 પ્રતિ સેકન્ડ કોઈ સમસ્યા નથી - વાંચન સમસ્યા.

તેથી, કેશ સાથેનો એક વિષય દેખાયો, અને તે જ સમયે અમે નીચેની સમસ્યાનું નિરાકરણ કર્યું: એક જૂનો પરંપરાગત કેસ છે જ્યારે ઓનલાઈન બિલિંગમાંથી સ્વિચમાંથી સાધનસામગ્રી ફાઇલોમાં આવે છે જે અમે કસાન્ડ્રામાં લોડ કરીએ છીએ. અમે IBM મેનેજર ફાઇલ ટ્રાન્સફરની સલાહનો ઉપયોગ કરીને પણ આ ફાઇલોના વિશ્વસનીય ડાઉનલોડની સમસ્યા સાથે સંઘર્ષ કર્યો - એવા ઉકેલો છે જે ફાઇલ ટ્રાન્સફરને અસરકારક રીતે સંચાલિત કરે છે, UDP પ્રોટોકોલનો ઉપયોગ કરીને, ઉદાહરણ તરીકે, TCPને બદલે. આ સારું છે, પરંતુ તે હજી મિનિટો છે, અને અમે હજી સુધી તે બધું લોડ કર્યું નથી, કોલ સેન્ટરમાં ઓપરેટર ક્લાયંટને તેના બેલેન્સનું શું થયું તેનો જવાબ આપી શકતો નથી - અમારે રાહ જોવી પડશે.

આવું ન થાય તે માટે, અમે અમે સમાંતર કાર્યાત્મક અનામતનો ઉપયોગ કરીએ છીએ. જ્યારે અમે કાફકા દ્વારા ટેરન્ટૂલ પર ઇવેન્ટ મોકલીએ છીએ, ત્યારે વાસ્તવિક સમયમાં એકંદરની પુનઃગણતરી કરીએ છીએ, ઉદાહરણ તરીકે, આજે માટે, અમને મળે છે રોકડ બેલેન્સ, જે કોઈપણ ઝડપે બેલેન્સ ટ્રાન્સફર કરી શકે છે, ઉદાહરણ તરીકે, પ્રતિ સેકન્ડ 100 હજાર વ્યવહારો અને તે જ 2 સેકન્ડ.

ધ્યેય એ છે કે કૉલ કર્યા પછી, તમારા વ્યક્તિગત ખાતામાં 2 સેકન્ડની અંદર ફક્ત બદલાયેલ બેલેન્સ જ નહીં, પરંતુ તે શા માટે બદલાયું તેની માહિતી પણ હશે.

નિષ્કર્ષ

ટેરન્ટૂલનો ઉપયોગ કરવાના આ ઉદાહરણો હતા. અમને Mail.ru ની નિખાલસતા અને વિવિધ કેસોને ધ્યાનમાં લેવાની તેમની ઇચ્છા ખરેખર ગમ્યું.

BCG અથવા McKinsey, Accenture અથવા IBM ના સલાહકારો માટે અમને કંઈક નવું આપીને આશ્ચર્યચકિત કરવું પહેલેથી જ મુશ્કેલ છે - તેઓ જે ઓફર કરે છે તેમાંથી ઘણું બધું, અમે કાં તો પહેલાથી જ કરીએ છીએ, કર્યું છે અથવા કરવાની યોજના બનાવી રહ્યા છીએ. મને લાગે છે કે Tarantool અમારા ટેક્નોલોજી સ્ટેકમાં તેનું યોગ્ય સ્થાન લેશે અને ઘણી પ્રવર્તમાન ટેક્નોલોજીઓનું સ્થાન લેશે. અમે આ પ્રોજેક્ટના વિકાસના સક્રિય તબક્કામાં છીએ.

ઓલેગ અને આન્દ્રેનો અહેવાલ ગયા વર્ષે ટેરન્ટૂલ કોન્ફરન્સમાં શ્રેષ્ઠ છે અને 17 જૂને ઓલેગ ઇવલેવ બોલશે. T+ કોન્ફરન્સ 2019 એક અહેવાલ સાથે "શા માટે એન્ટરપ્રાઇઝમાં ટેરન્ટૂલ". એલેક્ઝાન્ડર ડ્યુલિન મેગાફોન તરફથી પ્રેઝન્ટેશન પણ આપશે "ઓરેકલ તરફથી ટેરન્ટૂલ કેશ અને પ્રતિકૃતિ". ચાલો જાણીએ કે શું બદલાયું છે, કઈ યોજનાઓ અમલમાં આવી છે. જોડાઓ - કોન્ફરન્સ મફત છે, તમારે ફક્ત એટલું જ કરવાનું છે સાઇન અપ કરો... બધા અહેવાલો સ્વીકાર્યા અને કોન્ફરન્સ પ્રોગ્રામની રચના કરવામાં આવી છે: નવા કેસ, ટેરન્ટૂલનો ઉપયોગ કરવાનો નવો અનુભવ, આર્કિટેક્ચર, એન્ટરપ્રાઇઝ, ટ્યુટોરિયલ્સ અને માઇક્રોસર્વિસિસ.

સોર્સ: www.habr.com