Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マイクロサービスを成功させるためのサーバーレスアーキテクチャ設計とNoSQLデータモデリング ...

Masashi Terui
September 29, 2018

マイクロサービスを成功させるためのサーバーレスアーキテクチャ設計とNoSQLデータモデリング / Serverless Architecting and NoSQL Data Modeling for Successful Microservices

Serverlessconf Tokyo 2018

Masashi Terui

September 29, 2018
Tweet

More Decks by Masashi Terui

Other Decks in Technology

Transcript

  1. SERVERWORKS CO.,LTD. + FREELANCER • Serverless Oji-san • Serverless Framework

    Plugin Developer • Serverlessconf Tokyo 2016,2017,2018 speaker • Remote worker (in Sapporo-shi, Hokkaido) • The best Serverless Architect in Japan !!(Ͱ͋Γ͍ͨʣ MASASHI TERUI ARCHITECT / DEVELOPER
  2. SERVERLESS ARCHITECTURES (MARTINFOWLER.COM) “In the original version, all flow, control,

    and security was managed by the central server application. In the Serverless version there is no central arbiter of these concerns. Instead we see a preference for choreography over orchestration, with each component playing a more architecturally aware role—an idea also common in a microservices approach.” https://martinfowler.com/articles/serverless.html
  3. • Microservice(s)ͬͯ୯ޠ͕12ճ΋ग़ͯ͘Δ(͏ͪ3ճ͘Β͍͸ίϯςφͷจ຺) • “The orchestration of microservice workloads that execute

    a series of steps in a business process” • “Strongly promotes the microservices model, as most serverless runtimes enforce limits on the size or execution time of each individual function” • “Is the latency between the microservices, vs co-located features within a single deployment, an issue?” • “Once an application is split into multiple components, or microservices, you then have the freedom to deploy each one separately on completely different infrastructures, if that’s what’s best for your needs.” • “Likewise, each microservice can also be developed with the best technology (i.e. language) for its particular purpose. The freedom that comes with "breaking up of the monolith" brings new challenges though, and the following sections highlight some of the aspects that should be considered when choosing a platform and developing your microservices.” CNCF SERVERLESS WHITEPAPER
  4. • ෼ׂɾ౷࣏ • Functionͷཻ౓ • Serviceͷ੾Γํ • Observability • Monitoring

    • Log management • Traceability • ͭ·Δͱ͜ΖMicroservicesͱಉ͡՝୊Λ๊͍͑ͯΔ • ͜͜ʹڧ͍αʔϏεґଘͱ͍͏໰୊͕ՃΘΔ Ͱɺ࣮ࡍͷॴͲ͏ͳΜʁ
  5. • ίωΫγϣϯϞσϧ • εςʔτϑϧ • ޮ཰తͳϓʔϦϯά͕Ͱ͖ͳ͍ • ηΩϡϦςΟϞσϧ • ऑ͍ೝূڧ౓

    • VPC LambdaͷENIੜ੒Φʔόϔου • εέʔϦϯά • ·ͣਨ௚εέʔϧ • ݶఆతͳਫฏεέʔϧ FaaSͱRDBͷ૬ੑ͕ѱ͍ʁ
  6. • ίωΫγϣϯϞσϧ • εςʔτϨε • HTTP(S) • ηΩϡϦςΟ • ڧ͍ೝূڧ౓ʢIAMʣ

    • εέʔϦϯά • ਫฏεέʔϧ͕ϝΠϯ • ENIੜ੒Φʔόϔου͕ͱʹ͔͘ݫ͗ͯ͢͠ଞʹબ୒ࢶ͕ͳʢ͈́ FaaSͱNoSQLͷ૬ੑ͕ྑ͍ʁ
  7. • ϝοηʔδϯά • ಉظ/ඇಉظ • Interactive/PubSub • σʔλετΞ • εέʔϦϯά

    • σʔλΞΫηε • ࣮ߦํ๏ • ฒྻ/௚ྻ • ܾఆత/ඇܾఆత ໨తΛՌͨͨ͢Ίͷ࠷దղ͸ҟͳΔ
  8. • ಉظ • API Gateway • ඇಉظ • ௚ྻ •

    Kinesis Streams • ฒྻ • SNS • SQS • ͦͷଞ • Step Functions EVENTΛͲͷΑ͏ʹॲཧ͢΂͖͔ʁ
  9. • CloudFormation • SAM • Serverless Framework • ґଘੑͷ؅ཧɺEventSourceͱAction(Lambda)ͷඥ͚ͮ •

    એݴత • Ref • ImportValue/ExportValue ͲͷΑ͏ʹ؅ཧ͢΂͖͔ʁ Environment Variables
  10. for SAM (Stream -> Action -> Publish) Parameters: AppEnv: Type:

    String Default: develop Globals: Function: Environment: Variables: SELF_STREAM: !Ref FooStream BAR_TOPIC Fn::ImportValue: !Sub "BarTopic-${AppEnv}" Outputs: SelfStream: Value: !Ref FooStream Export: Name: !Sub "FooStream-${AppEnv}" StageΛParameter ͱͯ͠ड͚औΔ ࣗ਎ʹඥͮ͘Event SourceΛ Export͢Δ ൃߦઌEvent SourceΛ Importͯ͠؀ڥม਺΁
  11. • εςʔδ໊ΛύϥϝʔλԽͯ͠εςʔδຖʹEventSourceΛೖΕସ͑ΒΕΔ • ఆٛΛશ͘ม͑ͣʹ࣮αʔϏεΛMockԽͨ͠Integration Test͕Ͱ͖Δ • Outputs͔ΒEventSourceΛऔಘͯ͠ςετ༻ͷEventΛൃߦ • ͦͷAction͔Βൃߦ͞ΕΔEventͷର৅΋ಉ༷ʹݕূՄೳͳ΋ͷʹஔ͖׵͑Δ •

    σʔλετΞ΋ஔ͖׵͑Մೳ • શͯΛ઀ଓͨ͠ςετ΋ཧ࿦্Մೳ͕ͩͦ΋ͦ΋ςετࣗମ͕ࠔ೉Ͱ͋Δ • EventͱͦΕʹର͢ΔActionΛอূ͢Δ͜ͱΛॏࢹ͢Δ • ↑͜ΕΛCDCతʹ୲อ͢Δྑ͍ํ๏͕͋Δͱخ͍͠ Integration Test
  12. • “As emphasized earlier, most well designed applications require only

    one table, unless there is a specific reason for using multiple tables” • “Schema-less” ͷҙຯΛߟ͑Δ • List, Map͕࣋ͯΔ͜ͱʁ • શͯͷAttribute͕ඞਢͰͳ͍͜ͱʁ • A. ͳΜͰ΋ಥͬࠐΊΔ͜ͱ • ద੾ʹ෼ࢄͤ͞ΒΕΕ͹ςʔϒϧΛ෼͚Δඞཁ͕ͳ͍ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html DynamoDB Best Practices
  13. • Event Sourcing • CQRS(Command and Query Responsibility Segregation Pattern)

    • Materialized View • Eventual Consistency ॏཁͳཁૉ
  14. • ֤σʔλετΞͷಛੑ • DynamoDBͳΒPartition Key, Sort Keyͷ෼ࢄͷ࢓૊Έͱ͔ • σʔλͷ੔߹ੑΛकΔ࢓૊Έ •

    ACIDτϥϯβΫγϣϯ • σʔλΞΫηε • B+Tree Index • σʔλϕʔεͷجຊతͳ஌ࣝ • ͜Ε͕ͳ͍ͱͦ΋ͦ΋ద੾ͳબ୒͕Ͱ͖ͳ͍ ஌Δ΂͖͜ͱ
  15. DATA PLACEMENT Distributed by Partition Key
 and Indexed(B+tree) by Sort

    Key, LSI GSI is a projection of sorted(indexed) data