apim
2015/01/26
26 Jan, 2015

[Article] WSO2 API Manager Scalable Deployment Patterns - Part 1

  • Sanjeewa Malalgoda
  • Director - Engineering | Architect at WSO2 - WSO2
Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.

Introduction

WSO2 API Manager is a complete solution for publishing APIs, creating and managing a developer community, and for scalably routing API traffic. It leverages proven, production-ready, integration, security and governance components from WSO2 Enterprise Service Bus, WSO2 Identity Server, and WSO2 Governance Registry. Moreover, it is powered by WSO2 Business Activity Monitor, thereby making WSO2 API Manager ready for any large-scale deployments right away.

It is important to design an enterprise's server deployment infrastructure based on the business information gathered and design requirements. Users need to understand the limitations and identify areas of performance degradation to ensure that they design a deployment model that can perform well, regardless of the load.

WSO2 API Manager provides a scalable and flexible deployment option with complete control over infrastructure and management of APIs. It overcomes the challenges of building cost-effective, future-proof infrastructure that satisfies the user's and the organization's budgets.

WSO2 API Manager's functional component architecture supports effective deployment of a distributed setup. The choice of deployment option comes down to specific scalable requirements and cost. In this series, we will mainly focus on the following areas of discussion:

  • Single-server deployment
  • Cluster (with load balancer) deployment
  • Cloud deployment
  • Production deployment models
  • Fine-tuning and best practices
  • Solving common problems encountered with deployment patterns

When we deploy servers in production deployment, we should design the solution carefully. In this part, we will discuss the different deployment patterns and deployment models of WSO2 API Manager. Most of these deployment patterns are based on real-world use cases. You may have a different solution depending on your exact requirements.

Applies to

WSO2 API Manager Version 1.8.0 and above

Table of contents

  1. Understanding key components and data model
  2. Single-server deployment
  3. Distributed deployment
  4. Conclusion

 

Understanding key components

API Store

The API Store provides a space for consumers to self ­register, discover API functionality, subscribe to APIs, evaluate them and interact with API publishers. Here, users can come and view existing APIs created and self sign-in. Thereafter, they can create their own application by bundling multiple APIs together as one application.

Later, we will see how we can use these keys to make an actual API call. The feature list for the API Store is as follows:

  • View top used, new featured APIs and search by name, tag, or creator.
  • API rate, share comments, feature requests, and participate in forum discussions.
  • Create, manage applications, add/remove APIs to an application.
  • Generate application keys ­consumer and consumer secret keys for applications.
  • Regenerate new tokens if current tokens expire.
  • Download help and documents, contact business owners of API, and ask questions.
  • Self­ sign-up to the API Store.

Link to visit API publisher https://apimanager.com/store (URL may depend on the environment)

Applications

The application concept is used to decouple the consumer from the APIs and allows to: Generate and use a single key for multiple APIs Subscribe multiple times to a single API with different SLA levels. You must create an application to subscribe to an API. The product comes out of the box with a default application and you can create as many applications as you need.

Throttling tiers

Throttling tiers are associated to an API at subscription time and defines the throttling limits enforced by the API gateway, e.g. 10 TPS (transactions per second). At the pub­lisher level, the user defines the list of tiers that are available for a given API.

API Key manager server

This component is responsible for all security and key-related operations. When an API call is sent to the gateway, it calls the key manager server and verifies the validity of the token provided with the API call.

API gateway

The API gateway is responsible for securing, protecting, managing, and scaling API calls. It is a simple API proxy that intercepts API requests and applies policies, such as throttling and security checks. It is also instrumental in gathering API usage statistics. We use a set of handlers for security validation and throttling purposes. It passes web service calls to the actual back-end after these validation steps.­ If the incoming web service call is a token request, the gateway directly passes it to the key management server to handle. We can add/remove these handlers using the source view of the Synapse configuration. By default, all security and throttling handlers will engage with each new API created by the publisher. When it comes to production deployments, this server hits the highest number of requests as all API calls goes through this server.

API publisher

The API publisher enables API providers to easily publish their APIs, share documentation, provision API keys, and gather feedback on API features, quality of service, and usage. You can create new APIs by pointing to an actual back-end service. Moreover, we can define rate limiting policies available for that particular API as well.

Here are the some API publisher features:

  • Create, manage API, and publish them to gateway.
  • Monitor API consumers, behavior, response time, last accessed time, etc.
  • List the active subscriptions per each API.
  • Manage life­ cycle versions and policies. Based on the state of API, you can set it to any of the following states:
    • CREATED: API metadata has been added to the API store, but it is not visible to subscribers yet, nor deployed to the API gateway
    • PUBLISHED: API is visible in the API store. It will deploy in gateway if “Push to Gateway” option is selected at the time of publishing
    • DEPRECATED: API is still deployed in API gateway (available at run time to existing users), but not visible to subscribers. An API can automatically be deprecated when a new version is published
    • RETIRED: API is unpublished from the API gateway and retired.
    • BLOCKED: Access is temporarily blocked.

Data storages

User manager database

Stores information related to users, user roles, permission, etc. This information is shared among the key manager server, store, and publisher. In distributed deployment, we need to connect the usage manager database to the auth server (which is pointed by AuthServer configuration).

API manager database

Stores information related to the APIs along with the API subscription details. This database is used to store API-related metadata and runtime data. All tables in this database will contain the AM_ prefix in the table name.

Registry database

Used to store API metadata and other information. Shares information between the publisher and store.

Default carbon database (and database script) embedded with API Manager binary distribution will contain all required tables for registry and user management.

Single-server deployment

Single server deployment means running a single API manager instance with all components. If you extract the API manager's default binary product and start the server then it will run as single server (with API gateway, key manager, store, and publisher all in one). Normally, we use this single server deployment for simple deployments. We can use this for demonstration purposes and simple deployments with minimum load. If you have high volume traffic or you need high availability, then we do not recommend single server deployment. To run the WSO2 API Manager single server you do not need to configure anything. If you start the default product it will use the internal H2 database as the user management database and the API manager database. Furthermore, if you need to connect to an external database (like Oracle, MySQL) you can refer to the following configurations. Note that if you require statistics you need to configure WSO2 API Manager with WSO2 Business Activity Monitor, which we'll discuss later in this article.

Configurations

To edit WSO2 API Manager related configurations, you need to edit api-manager.xml file located at /repository/conf directory of product distribution. To learn about configurations refer to this document.

To configure data sources and database-related configurations, you need to edit master-datasources.xml file available at /repository/conf/datasources directory. In a basic, single-server deployment, we do not need to point to registry, user manager, and API manager databases. User manager and registry data will be available in the Carbon database, and all API management specific data will go to WSO2AM_DB. These two are the only tables required for single-server deployment. Yet, depending on your requirement, you can point the server to relevant external databases.

01. WSO2_CARBON_DB

02. WSO2AM_DB

Configurations related to user management are available at user-mgt.xml file in /repository/conf directory (add, edit user store, etc.).

Configurations related to registry are available at registry.xml file in /repository/conf directory (add, edit user store, etc.).

API Manager single server deployment.

 

Fully distributed deployment

In distributed deployment, we deploy four components (gateway, key manager, store, and publisher) in four different servers. This is one of the most common deployment patterns. There are some advantages of this deployment. Each component runs on a dedicated server, therefore we can assign resources and fine-tune nodes according to the requirements of components (e.g. if its gateway, we can tune gateway-related configurations, such and Synapse worker threads, gateway time out, etc.).

We can easily scale up or scale out only the required server resource. For example, let's say we have a very high number of gateway requests. At the same time, we may not have considerable amount of traffic to store and publisher. We can also consider vacation week; within that period, API developers may be on leave, so there will not be any API or application development via API store or publisher. As a result, there will be minimum traffic to the store and publisher. However, due to vacation, external users may use mobile/web applications to buy things, and as a result, traffic to gateway will increase. In such cases, we can scale out only gateway and key manager nodes according to traffic, and utilize resources properly.

Easy to trouble shoot or identify issue. Let's say we identified some issue in the API store node and need to patch it in production deployment. In such cases, we can apply a required fix to only store node and it will not have any impact on gateway or publisher functionalities. One server type outage will not affect to entire solution.

Sometimes users need different components in different zones. For example, we normally deploy API gateway in DMZ and key manager in MZ. If opt for such a deployment model, fully distributed deployment would be the ideal solution.

,

API Manager distributed server deployment and connectivity between components.

 

Conclusion

In this article, we discussed the basics of WSO2 API Manager deployments. The article mainly focused on basic components, their relationship, single server deployment, and fully distributed deployment. In the next parts of this series, we will discuss more advanced topics like scaling deployments, deployments across data centers, etc. We will discuss the following topics in detail:

  • How to deploy across zones
  • Message flows of sample deployment
  • Integration with workflow engine
  • Enabling statistics for WSO2 API Manager
  • Multi data center deployment
  • Deployment with online/offline monitoring
  • How to scale up and scale out
  • API Façade deployment pattern
  • Amazon EC2 deployment
  • Fine-tune deployment

 

References

[1] https://wso2.com/products/api-manager

[2] https://docs.wso2.com/display/AM180/WSO2+API+Manager+Documentation

 

About Author

  • Sanjeewa Malalgoda
  • Director - Engineering | Architect at WSO2
  • WSO2